I am trying to understand https://docs.pactflow.io/docs/bi-directional-contract-testing/provider. Why would I want to publish a failed provider verification? If my provider verification test fails, my pipeline will be in a failed state. I will never move on and e.g. try to install this on an environment. I already know the version is broken.

a developer may make a change to the provider description but not the implementation. They would still want to know • is the provider impl compatible (in this case, no) • is the provider description compat with all consumers (yes or no - but you only find this out if you publish) the simplest way to setup your ci system, is to run two publish jobs, one which runs if the previous tests failed. they should take the exit code of your test suite ideally. If you have notifications setup in your Pact Broker you can notify teams of the self verification failure or cross compat failure, or both

I still don't get it. When the developer changes the OpenAPI spec, the build will run and fail again. I will never get into the situation where the provider would be published with a failed verification. The consumers don't need to know about the failed verification. They just need to know that the version they want to deploy is compatible with the version that is running in the env of the provider.

what if the developer fixes the change, gets the tests passing, publishes the contract to PactFlow and its incompatible with a consumer, and that wasn’t their intention. They have wasted time, when they could have gotten early feedback that the OpenAPI document isn’t compatible with x consumer

when the developer fixes it, we get a new version. This is perfectly fine and doesn't care about compatibility. I don't see how an open API validator would be aware of the consumers anyways. The compatibility check comes later into play when doing the can-i-deploy.

pactflow is aware of the consumers because it tracks them and their expectations of the provider api

all step 3 does is verify that the provider against its open API spec

correct it is checking for provider drift, have the provider impl drifted from the spec

the developer cares about compatibility, just not when running the verification

has*

what I don't understand: how would I know at build time that my provider is incompatible with the deployed consumers?

build time as in CI, or on the users local machine? if CI. provider runs self verification provider publishes results pactflow performs cross compat check against all deployed/released consumers provider performs can-i-deploy check (or can-i-merge) which checks pactflows cross compat results

build time as in CI in our case, provider will not publish any failures. It will only report successful verifications. The cross-compat checks are then obviously nice (and the reason we want to use this feature). through can-i-deploy (or can-i-merge, I haven't looked into that yet) we make sure only compatible versions are deployed.

fair enough, well i’ve told you the rationale as to why people use it, the configurability is there to use it, in whichever ways works for your workflow, it isn’t a mandatory step so you are more than welcome to skip it

I still don't understand the rational. 🙂

make a change to the spec, push the change, provider tests may fail, contract published to pactflow, cross compat checks conducted. you immediately know the consumers you will impact in order to co-ordinate the change, without expending any development effort on the provider implementation. In your case, you would have to change the spec, update the impl, update the tests, get a green build, to then find out you need to go co-ordinate with two teams, or change your initial approach to not impact consumers

in my case, the devs wouldn't even push (ideally) because the test (verification of OAS spec against implementation) are failing. They would then fix it. You are suggesting to adapt the specification, pushing that to the CI system, knowingly breaking the build, to then let pact compat-checks kick in.

that is good to know, as CDCT offers the strongest benefits. No problem, sounds like you have a good flow. We’ve seen the pattern I’ve described at a few spec first organisations, and users have commented on how they appreciate the flexibility to fit the tool into their workflows rather than the tool forcing them into a specific one

thanks for clarifying. Obviously, pactflow is in another situation than I am. I can mandate or just push certain ways of working and not talk about others 😉