I was hoping to get a bit of guidance on making changes to existing pacts. We’ve had our pact process setup for quite a while and have mostly followed the CI/CD pact process. This has been working well, on the provider we’ve enabled pending pacts and WipPactsSince… However, we recently needed to make a breaking change on our schema for our provider. (changing a property type from string to number) - js. This didn’t cause any breaking changes on our consumer side, but we ran into issues when trying to ‘deploy’ the changes because of the can-i-deploy didn’t have a deployed version of the provider that had that change. However, I can’t deploy it to the provider because it’s considered a ‘breaking change’ and tells me there is no verified pact between the version that is currently deployed or released to test. I know there’s a ‘right-way’ to handle this, but I can’t seem to figure it out based on the documentation here: https://docs.pact.io/pact_nirvana/step_7 I’ve got everything in place (minus the webhooks) The error I get when trying to ‘deploy’ the provider is there is no verified pact between the version of the ‘consumer’ current deployed or released to test and version ‘provider_version’ of ‘provider’

Yeah I think that is the trick, you make it backwards compatible and then can remove once consumers have updated and deployed using the new property. I believe I saw there is an escape hatch via an env bar, Beth mentioned it the other day, will have a quick look in the docs when I am at the keyboard

I guess the real trick here is the fact that we made a ‘breaking change’ and we should have provided backword compatibility. Since we didn’t we just have to disable the can-i-deploy checks for the provider for now to get a valid build out there?

You can definitely make a “breaking change” (breaking in the traditional sense) to an API, provided that no consumers would be impacted by the change. At the time of deployment, the provider must be compatible with the consumer in the target environment (e.g. environment=

prod

) and probably with the current mainline (e.g. branch=

main

)

Ok, I can see a couple of unrelated issues here. 1. is that Pact will not let you make the change you just described. You will have to ignore the failing results if you want to get that change into prod and 2. I don't think the error you're seeing is because you're making a breaking change, I think it's because there is something not set up properly, so you're missing a verification result. In regards to the can-i-deploy failure: in the can-i-deploy error message, does it tell you that there is no consumer version deployed to test, or does it give you the version number that is missing the verification? What are the consumer version selectors you have configured to be verified in the provider verification? In regards to the breaking change. Pact will never let you make this change in one deployment if the consumer is actually using that field, because it will force you to be backwards compatible with the consumer in prod, and if you update the pact in development, the field can't be both an integer for dev and a string for prod at the same time. The only way you can transition from a string to a number would be to add a new number field, deploy provider, switch all the consumers to use that new field, deploy consumers, change the old field type (because by this stage, none of the consumers are using it, so none of the pacts will fail) then deploy the provider, then update all the consumers to use the original field again. This is the "expand and contract" pattern https://docs.pact.io/faq#how-can-i-make-a-breaking-change-to-a-provider

Nice, we can probably expand on that, in the FAQ on the docs site (plus we get the chance to get two tv/movie references) - I am definitely too much of a fan of Spaced

what if I need to deploy, but Can-I-Deploy (computer) says no?

Buckle your seat belt, Dorothy, 'cause Kansas is going bye-bye. Set x flag.

Yes, it's a good faq question

thank you all, this is really great clarification! In our case passing in the --dry-run flag was what we needed for the can-i-deploy. We had the new pact verified on the main branch, but when we did the deploy check it would fail as the change was ‘technically’ breaking our consumer (even though it wasn’t) - because js doesn’t care much about types

yes, this is really annoying! unfortuantely, we're still waiting for the last of the main clients to be updated so that we can do a wholesale update on the site.

if you catch any you've found, you can add it to the snagging list here on the GitHub docs, appreciate the feedback on the docs Kyle

In regards to the can-i-deploy failure: in the can-i-deploy error message, does it tell you that there is no consumer version deployed to test, or does it give you the version number that is missing the verification? What are the consumer version selectors you have configured to be verified in the provider verification?

What it was showing was

There is no verified pact between version 1.0.0-CONSUMER-203 of consumer-ui and the version of provider currently deployed or released to test (1.1.3-1653402689-main-249)

on the consumer can-i-deploy check

That tells me that you're missing the webhook, as you mentioned earlier, that triggers your missing verifications https://docs.pact.io/blog/2021/10/11/contract-requiring-verification-published-webhook-event

yeah firewall issues there 😞

wonderful.