Hi all, Our org is running into an issue with CICD implementation. Specifically when a dev updates a provider and breaks consumers. How is the dev supposed to get the pipeline into a green state in order to merge into main? Currently we have the can-i-merge check happening which fails as the current dev work has broken the pact. So dev finds consumers and updates them, but CICD can-i-merge check still fails since provider work is on a feature branch and consumer update is on a feature branch, not main. We’re now soft-locked from introducing any change. I read a bit about WIP pacts and pendingpacts, However im not seeing where those settings are to be set or really any example using them. Were utilizing all our pact commands with Cypress & pact-broker-cli. Any help is appreciated, Thanks!

Have you read / done the CI/CD workshop? It both explains those concepts and shows a demo app (howtolearn)

Here are a number of useful hands-on labs that teach all of the key concepts: https://docs.pactflow.io/docs/workshops and https://docs.pact.io/implementation_guides/workshops

Appreciate that. Thanks for the links, I went ahead and completed the CICD tutorial but am still struggling. In the CICD tutorial here, it goes over a consumer driven approach however part of the steps require updating the provider directly on the

main/master

branch, which is obviously not feasible. Mix in that our org usually drives changes from the provider and im not really seeing anything on a

provider

driven approach. Do you happen to have more info on

provider

driven cicd approaches?

ah, do you mean bi-directional contract testing?

yeah, exactly

WIP and Pending aren’t relevant for BDCT, so you can ignore that.

the dev would add integration tests in the same pr with their breaking change and also update “consumers” that it breaks

it’s worth seeing if it helps

appreciate the insight and yeah your right. Ill see if can-i-merge solves one of our issues

if they are valid on the branch, but not against main, and you can’t make either party tolerant of the backwards and forwards versions, you have the information to progress the provider and consumer into your main branch. They won’t be compatible with the deployed consumers, but will be compatible with the main branch. You’ll then need to co-ordinate deployments with potentially some outage whilst they both deploy. Pact is simply informing you of your situation and it is up to your team to resolve it.

We’re now soft-locked from introducing any change.

That is of your own making, not by Pact, Pact is simply informing you of it.

got it, so can-i-merge and can-i-deploy are correctly failing since this is a breaking change against main. Its now up to the dev to either: 1. make the provider backwards compatible or 2. release the breaking change with follow-up work to update consumers

release the breaking change with follow-up work to update consumers

I wouldn’t release it without the work having already been done to the consumers, and then its a case of just deploying them all within a certain change window. I.e you know the new consumers will be compatible with the new provider.

right the consumer update work should be ready to merge as soon as the provider update is merged

but either of those options are feasible, usually option 2, with the work passing on a feature branch and then deploying at the same time (ish) will work for some teams depending on how they release (last client has change windows, so all the ci/cd in the world didn’t help us get straight to prod 😅 )

This is really helpful, thank you!

pleasure dude, it’s kinda a head-scratcher at first, but becomes more natural. I had everything flipped when we went cloud / microservices based and rolling out changes which were relatively trivial when everything all lived in one code base, because a bit of a juggling act when using microservices. Feel free to pop up more questions as you get them 👍