Question about best practices for picking up changes to pactfile. Context: 2 microservices, called

PotatoConsumer

and

PotatoProducer

ireland 🥔 with separate everything - pipelines, repos, deployable artifacts. Owned by a full-stack team that communicates well.

PotatoConsumer

updates the Pactfile (for

$reasons

). The update would cause a failure in

PotatoProducer

because it no longer upholds this contract. HOWEVER, because the pipelines etc are all separate, the failure in

PotatoProducer

doesn't get picked up until the next time someone touches it, six weeks after `PotatoConsumer`'s deployment to production (let's assume it fails in a subtle and unnoticed way). What's the best way to avoid this without ending up with pipelines doing super weird things to each other?

Hi @Paula Muldoon 👋🏻 We currently have a setup, where this contract change would trigger a new build that would run the provider pact verification tests in the provider side (via a webhook configured in the pact broker) We’ve set it up in a way that if this build fails, it notifies the producer team via slack.

thanks @Jaswanth M! If the build fails, does it block anything on the consumer side?

The consumer when they post their pact, if it has never been verified by the provider, will trigger a contact content changed and contract requiring verification published event. A provider build ( seperate from their usual build ) will be triggered to check out the code for all deployed/released versions of the provider and the head of the main branch to check comparability. Consumer would fail can I deploy, or can poll for a specified time to wait for the providers build to run. If the provider doesn’t have a sep build that it triggered by the contract changing, they can pick up the changes during their regular CI run by using Include WIP pacts Enable pending pacts. Wip pacts would allow the contracts published but not verified to be picked up by the providers ru. Enable pending on provider side would stop the consumers change a) failing the providers build so they can still deploy b ) block consumer until the provider has deployed a compatible change. I would expect consumer to back out change from main and then co ordinate on the change as a feature, that would allow consumers builds to continue for changes unrelated to that feature

ooh thanks @Yousaf Nabi (pactflow.io) that's really interesting!

Hi @Yousaf Nabi (pactflow.io) 👋🏻 thanks for that ultra clear explanation 🙌🏻 1. Yup we’ve moved away from tags and use the branches instead 👍🏻 2. We are still perfecting our webhook setup. Since we don’t have dev or staging branches. We only have feature and main (Trunk based branching). We’ve been running through different scenarios to see how best we can set it up. Have you seen any approaches for trunk based branching before ? Would love to hear from you and the community.

HOWEVER, because the pipelines etc are all separate, the failure in PotatoProducer doesn’t get picked up until the next time someone touches it, six weeks after PotatoConsumer’s deployment to production (let’s assume it fails in a subtle and unnoticed way).

This shouldn’t be possible.

Happy new year! We are doing team programming tomorrow and trying out this demo. This all makes sense - thanks (didn't know the contract has to be verified) and

can-i-deploy

looks just the ticket.

Happy new year! Awesome sounds like fun, have a good day tomorrow 🚀 Feel free to reach out on here or send your teammates here is they have any other questions 🙂