Hi, I'm trying to understand if I don't have any misunderstanding of the provider pipeline. Let's review the example of provider pipeline (very simplified, only pact invocations): •

pact verify

(verify consumers according to selectors) •

pact can-i-deploy

(check if this provider version is safe for deploy) If

pact verify

step fails when the provider breaks one of it's consumers and the pipeline invocation is interrupted - does it actually make sense to have

pact can-i-deploy

as the next step at all? Is it a false assumption that both commands either pass or fail together?

No, that makes sense. Failing verification means there’s a potential integration issue and you’ll likely want to investigate and resolve that before you deploy. Also don’t forget the

record-deployment

or

record-release

step after successful deployment to update your broker with the latest versions in your target environment.

Does it mean that

can-i-deploy

is mostly for the consumer, whereas provider is guarded by failing

verify

task?

You could say that, but only if those steps are part of the same pipeline

yep, that’s mostly true Serhii. There are some nuances to it, however. If your provider build verifies both production consumers and main branches (or others) and fails, it may still be safe to release to production. e.g. if your provider verification has the recommended or default selectors, or default selectors, and all but the

deployedOrReleased

pacts are passing, you may still decide to deploy to production. This is where you need to map it onto your workflow. But as a general rule, you want your verification task to be green before deploying. We also recommend running

can-i-deploy

directly prior to release, in case of any race conditions between steps where the situation on the consumer side has changed.