Hello, I am testing out Pact before adoption at the company and I'm going through a simple failure scenario. I have 2 repos, one for the consumer and one for the provider https://github.com/muratkeremozcan/pact-js-example-consumer https://github.com/muratkeremozcan/pact-js-example-provider Things seem to be working well, with CI, webhooks, etc. etc. I am going through a simple scenario, where the getAll response changes from 200 to 201. The flow is simple but I am running into a chicken & egg situation 1. Things are working 2. Make a simple change 3. Now get the change through I can't deploy the provider because it needs the consumer to be deployed first, but I can't deploy the consumer either because it also requires the provider to be deployed first. Here are the consumer changes, the test now expects a 201 https://github.com/muratkeremozcan/pact-js-example-consumer/pull/11 Then I update the provider, making the changes that should handle the test https://github.com/muratkeremozcan/pact-js-example-provider/pull/3 When I run the provider test, it tests the provider main version against consumer commit sha, because of the config at the test

consumerVersionSelectors = [
  { matchingBranch: true },
  { mainBranch: true }, // have to disable for the provide test to pass
  { deployedOrReleased: true } // have to disable for the provide test to pass
 ]
}

The only way it can work in this flow is by disabling testing against main & deployed and released. That way , execution in main of consumer happens against the main of provider, execution of the branch name happens against the branch name of a provider. When we do that though, it gets blocked at can i deploy for both the consumer and provider. I believe my scripts are setup optimally https://github.com/muratkeremozcan/pact-js-example-provider/blob/main/package.json#L13 https://github.com/mdcruz/consumer-example/blob/main/package.json#L8 If you're willing to give it a whirl, I can share the token and the base url. Everything is reproducible locally.

based on your consumer pr, there are no updates to the consumer code (just test code), so your consumer code should work with a 200, or 201 response returned. you could leverage status code matchers, to relax your condition on the status code to not expect a single status code. Otherwise more generally Pact is giving you information that the change you are proposing cannot be made easily in an expand and contract pattern and therefore must be a breaking change. Pact identifies your consumers affected by that change, and gives the consumer/provider teams information of which to determine their best course of action. The can-i-deploy tooling allows for a dry run option, which can be set by an env var and is used for break glass scenarioes, but these also may be scenarioes where you are deploying services within a change window, because you know there will be an potential outage (period where the two deployed services are unable to communicate until both new services are deployed)

thank you very much @Yousaf Nabi (pactflow.io) I will ponder on your response

my pleasure, thanks for the examples (repro’s are always much appreciated). I’ll try them out when I get some time and apply my thought process and see how it pans out in your scenario.

yea, I think the recipe thing is somewhat open to improvement on Pact’s side I will keep making those repos better, like convert to TS, deploy the provider (maybe vercel for express) change the data model, start using some real db (like sqlite) , maybe add cy e2e , Optic schema testing, Mockoon api mocking to compare and contrast how you’d use pact alongside or versus other tooling out there These are all great scenarios to exercise with pact

They all sound like brilliant additions, and we would gladly help showcase your repo for others. We have a tricky balance to strike as maintainers, as we look over lots of different repos for diff client languages, all of which are agnostic about which test framework the user chooses. Building up examples to cover every use case, quickly becomes a maintenance nightmare, and can go beyond the scope of Pact/Contract testing quickly, which negates the overall value the example has for the Pact community. I think as a maintainer, I would rather invest time updating each of the pact workshops to 1. utilise best practise for each language (some of the workshops were initially created some years ago, and would be created differently with newer programming features in each lang 2. Showcase each Pact feature (ie all variants of matchers/generators, provider states with params, etc) in a consistent fashion across each language. None of that should stop you building out a flagship template for your language of choice though, they are incredibly valuable for end-users, and for me in the past have been a great learning experience