For teams using a feature branches where published pacts are Pact Foundation #pact-broker

For teams using a) feature branches where publishe...

Rafael Anachoreta

03/03/2022, 5:28 PM

For teams using a) feature branches where published pacts are tagged and have

branch

set, b) the new

contract_requiring_verification_published

webhook event to trigger new verification and c) the

deployedOrRelease

selector pointing to the main branch, is there any benefit to having WIP and Pending pacts enabled? From reading the docs, they seem to me more like a safeguard for teams that haven’t figured out their workflow, but maybe I’m missing something.

Beth (pactflow.io/Pact Broker/pact-ruby)

03/04/2022, 2:07 AM

should be the same benefits.

Beth (pactflow.io/Pact Broker/pact-ruby)

03/04/2022, 2:08 AM

the workflow is the same for tags/branches+environments, even if the Pact Broker features used a different.

Beth (pactflow.io/Pact Broker/pact-ruby)

03/04/2022, 2:09 AM

You'll still want to ensure that a consumer can't break the provider's build by putting a breaking change onto their main branch (which is what pending pacts does) and you'll still want the pacts from the outstanding feature branches to be verified when you run the provider build (which is what WIP pacts does).

👍 1

Rafael Anachoreta

03/04/2022, 10:00 AM

That’s true, but if all consumers are running can-i-deploy and if my provider targets my main branch only, then I can’t think of a scenario where incompatible consumer changes would be merged. 🤔 Though they definitely don’t hurt either I suppose one scenario could be a consumer for some reason skipping can-i-deploy.

Open in Slack

Previous Next