Hi all! 👋 Does bi-directional testing support anything similar to pending states? Im trying to add bi-directional testing to my pipeline, I want consumer's pull requests to be checked against the latest provider version, but I don't want those checks to fail if they're hitting endpoints which hasn't been published yet in our provider. Also, where do we bind consumers with providers in a bi-directional workflow? Can a consumer have multiple providers? Would this require having a pact for each provider? Thank you for your work btw, Pact is amazing 💪!

Hi Juan! I don’t believe we currently support pending for bi-directional. But I think what you’re asking is a bit different to what pending is - pending is a provider feature, not a consumer one. The consumer’s build should always fail if it’s not compatible with its provider

Also, where do we bind consumers with providers in a bi-directional workflow? Can a consumer have multiple providers? Would this require having a pact for each provider?

Yes, exactly. The provider can actually publish its contract in advance, but it doesn’t advertise its consumers. When a consumer publishes its contract, an integration is established. Each consumer must have its own pact with a provider, yes, because otherwise we can’t track (down to the field level) what each consumer needs of a provider at any point in time

The consumer’s build should always fail if it’s not compatible with its provider

In our case, we're maintaining several consumers and providers. When a new feature is requested, it's very likely to be implemented in a consumer before it's provider pact is published (we define the api beforehand, but publishing a pact requires for our integration tests to be written, which takes some days). We want to prevent our teams blocking each other, having consumer pull requests to be blocked until providers have finished publishing their pacts would prevent us from implementing can-i-deploy. Our consumer team usually creates one pull request for each endpoint, a new feature consisting of 4-5 different pull requests. cross-validation would prevent us from having these partial merges, as it would require for all the api to be implemented at once. Another use case, when a feature is ready in our consumer, but still under development in our backend, we release it as feature-flagged to our lower level environments (or even prod in some scenarios) to show QA the UI and check if there's any undesired side-effect, while the provider is being completed (i.e, maybe we only managed to implement a POST, GET and summary endpoint, but DELETE an PUT are still pending development) So, should I not use cross-validation on consumers at all?

having consumer pull requests to be blocked until providers have finished publishing their pacts would prevent us from implementing can-i-deploy.

that choice is entirely yours. With bi-directional, you actually use

can-i-deploy

to determine compatibility (unlike with regular pact in which case you need to see a valid verification result from a provider for a given pact). But in either case, all we can tell you is what we know about compatibility. Usually, you would leave a PR to be red until such time that the provider implements the feature, at which point the PR should be green and ready to merge. See this workshop for the recommended flow: https://docs.pactflow.io/docs/workshops/ci-cd/

. We want to prevent our teams blocking each other,

of course! But also you can’t escape reality, if the consumer is not compatible with a provider yet, then we’ll tell you about it. If you know better, then you’re free to override the results of

can-i-deploy

of course.

Another use case, when a feature is ready in our consumer, but still under development in our backend, we release it as feature-flagged to our lower level environments (or even prod in some scenarios) to show QA the UI and check if there’s any undesired side-effect, while the provider is being completed (i.e, maybe we only managed to implement a POST, GET and summary endpoint, but DELETE an PUT are still pending development)

see also https://docs.pact.io/pact_broker/tags/#using-tags-with-feature-toggles-instead-of-feature-branches and https://docs.pact.io/pact_broker/tags/#for-feature-toggles-in-the-consumer

if the consumer is not compatible with a provider yet, then we’ll tell you about it

I'm looking for a middle point where it ignores missing endpoints, but complains if an existing endpoint isn't compliant. I'll try to extend that functionality by downloading the verification results

see also https://docs.pact.io/pact_broker/tags/#using-tags-with-feature-toggles-instead-of-feature-branches

Sweet, that's exactly what I was needing! Thank you Matt, much appreciated!

Resurrecting this thread for a different use case. We are using an api gateway and writing contract tests in the gateway, but adding a new consumer contract there breaks the pipeline if the provider oas isn't set up yet and we have no way to set the consumer to be a WIP pact. Overriding isn't a great option every time temporarily and once the consumer contract is published, it breaks all branches of our CI/CD (unless we set it up wrong) since it pulls all pacts from the pacticipant list even in adjacent branches (i.e. wip pact is on PACT-123, but renovate-123 sees pacts from it's branch and on PACT-123). Thoughts? @Matt (pactflow.io / pact-js / pact-go)