How can I ensure that none of our developers are able to game the system somehow as we see some room for it? My particular question is that if Provider decides to write the pacts when consumer is not ready, How do I ensure that

can-i-deploy

is accurately telling me that both consumer and provider are in sync if I never ran the consumer test yet?

What do you mean by “provider writes the pacts”? Do you mean publishing their provider contract (an OAS) that is invalid?

Continuation from point 2, Do I have to run both consumer and provider tests if consumer pact was developed after the provider test in order to release the consumer?(I think so but just wanted to confirm if there is a different approach or not)

In the cases of BDCT no (because the OAS is not changing, getting the provider to re-publish the same OAS doesn’t give us any new information). With the Pact model, yes, because the provider must verify each contract individually

Could you please let me know if this is the right forum to bring these questions up, or if I should bring them up elsewhere

You’re in the right place 🙂

For this https://pact-foundation.slack.com/archives/CLS16AVEE/p1660001885006759?thread_ts=1659998145.922109&cid=CLS16AVEE, I figured out the answer I was looking for. Thank you!

https://pact-foundation.slack.com/archives/CLS16AVEE/p1660007379263709?thread_ts=1659998145.922109&cid=CLS16AVEE - If I only validate the consumer pact to OAS in BDCT, how would verification results be published to pact broker and how does

can-i-deploy

fit into this? This page isnt very clear about that. I conceptually understand the diagram but practically, I am making assumptions that I am not 100 percent sure of.

Consumer based contract test is quite straight forward, but If I wanted to have a Provider based contract test where provider code is developed first, this is the workflow I see happening without use of Swagger hub; 1. Provider creates the contract if provider is ready first or is in earlier development.(This is done first time or only when consumer is not ready or needs a change as a result of a broken contract) 2. Provider publishes the contract to broker.(This is done first time or only when consumer is not ready or needs a change as a result of a broken contract) 3. Provider validates the contract against its own open api spec json file generated during Integration tests(If executed before contract tests) or contract test generates it itself as a before test hook. - I almost have a working example for this with

swagger-mock-validater

. 4. Provider runs provider tests and publishes passing results to broker. - At this point Provider doesnt care about an actual consumer because there is none. 5. Provider publishes the open api spec json to artifactory. 6. Provider runs

can-i-deploy

pact CLI command to verify if provider is ready for release against the pact-broker. 7. Provider can release if step 1 to 6 are passing. 8. Consumer development begins and consumer writes a consumer contract. 9. Consumer retrieves the published provider open-api spec json from artifactory to validate pact against it using same tool as step 3. 10. Consumer publishes the contract to broker. 11. Consumer triggers the provider tests by cloning the provider repo with latest version specified in

gitops-version

and actually runs the provider tests to publish the verification results to pact broker.(May not be needed since a comparison with OAS is sufficient - Confirming with Pact team) 12. Consumer runs

can-i-deploy

to verify if consumer is ready for release. (May not be needed since a comparison with OAS is sufficient - Confirming with Pact team) 13. Consumer can release if steps 8-12 passed. 14. A month later, provider changes its code, breaking the contract but does not know it yet. 15. Provider repeats steps 3-6 to verify that its not breaking the contract with the consumer(This time it does care about consumer because a released or an active version of the consumer exists). 16. Provider fails on the repeated step 4 as the tests will fail because code was modified in step 14. 17. Teams coordinate the failure and decide if the fix needs to be on provider or consumer side. 18. If provider makes the fix, then contract is reverted to original content and steps 3-6 are repeated. If consumer has to fix, Then steps 1-12 are repeated and both provider and consumer are released together to ensure accurate interface in production.

1. Consumer runs

can-i-deploy

to verify if consumer is ready for release. (May not be needed since a comparison with OAS is sufficient - Confirming with Pact team)

both provider and consumer should always run that command prior to deployment

Teams coordinate the failure and decide if the fix needs to be on provider or consumer side.

Yes, that too. Ideally, the provider uses an expand and contract pattern, and never breaks a consumer. But of course we live in the real world, and sometimes that’s not possible

@Matt (pactflow.io / pact-js / pact-go) I needed some help with BDCT with pactflow. I wanted to check with you how contracts appear instead of pacts

Would you or someone from the team be able to meet with me for 15 to 30 mins?

Actually, I will spend some time today to get it working. If I stumble upon any outstanding questions, I will reach out. Thanks Matt!

@Matt (pactflow.io / pact-js / pact-go) I got bidirectional flow started for two of our services in pactflow. We are a large organization with lots of micro-services so we will likely be headed towards the enterprise or paid version. I got the OAS uploaded from provider side and also see it in correct format in pactflow ui. But when I upload the consumer pact, I see this error.

It's only telling me about a validation failure. I don't see any obvious issues in the open api spec on the pactflow ui