Hi team. I’m new to Pact and contract testing in general. I’m working on a POC with Pactflow and I seem to have a chicken and egg dilemma with

can-i-deploy

in CI when a change is made in the contract to an existing field’s data type/expected value. For example: • Verified contract between consumer (

main

branch) & provider (

main

branch) has JSON response body field

age

as an integer • Consumer team publishes revised contract (

feature-age

branch) to update

age

to be a string. Contract for

feature-age

branch has status “Unverified” so

can-i-deploy

check in CI fails for no verified contract w/ provider. Pull request is blocked from merging to

main

due to failing check. • Provider team implements change to

age

field changing it from integer to string in a feature branch and creates a pull request. Pull request

can-i-deploy

CI check fails verification because latest version of

main

branch in the consumer still has

age

as an integer (consumer PR is blocked from merging). In this situation, neither the provider nor the consumer can merge PRs to implement the data type change to an existing field. I’d like to prevent a consumer from merging to

main

if a contract is unverified or failing when comparing to its provider(s)

main

branches. And vice versa for providers.

can-i-deploy

seems to fit the bill for that as a CI check when adding or removing fields, but when I try to change the data type/expected value for a field, I hit this wall. Any guidance would be appreciated!

Of course. You’ll have a deployment timing issue if you do it this way. The “correct” way to do this sort of thing is via “expand and contract” strategy here.

Ahh, I like that solution as it allows us to add a deprecation notice on the old integer field and continue to support it for a while until all consumers have migrated to the new field. Thanks a lot Matt, I appreciate the help!