Hi Team, I have a couple of questions regarding the behavior and configuration of Work In Progress (WIP) pacts. 1. In a scenario where the WIP feature is enabled and a new contract is published to a WIP branch, but the provider hasn’t yet implemented the expected state or supported the feature, the provider pipeline won’t fail due to pending pacts being enabled. However, if the consumer pipeline includes a

can-i-deploy

step to check verification status—will this step fail, or still pass? 2. Also, according to the documentation, enabling WIP pacts initially seemed to require no changes on the provider side. However, I noticed that the

includeWipPactsSince

property is mentioned as part of the provider verification configuration to include modified pacts. Could someone clarify whether this property is mandatory for enabling WIP pacts on the consumer? Appreciate your insights!

yes the property is mandatory on the provider side to verify pacts which are considered to be wip - that they have no previous successful verification. without this property, those pacts would not be retrieved for verification can-i-deploy would fail for a wip pact, as no verification, or a failing verification would be returned. the docs state the includeWipPactsSince is required on the provider side. where did you read otherwise? the docs you point to make it clear in the third bullet

It was mentioned in the first 2 lines, though. 😉

without requiring an update to the provider configuration.

it says in the next line how to enable it. the feature has to be enabled for it to work, and then it is config free

Also, can I tag 2 different branches to a provider, so that the consumer's main branch doesn't fail during the can-i-deploy step, while we have the new pact in the WIP branch?

you wouldn’t use a

tag

, you would use a

branch

you want a combo of WIP pacts and pending pacts. pending pacts stops the provider from being blocked, if the consumer pushes their wip pact to master. only the consumer will be correctly blocked. consumer should therefore publish new features to a branch, not affecting master, and only merge when verifications are complete (and therefore a pact is no longer a wip). If there are no changes to contract content, then verification is automatically applied from last successful verification of the same content generally, when using webhooks, to trigger verifications when a contract is published that requires verification, the provider build is always kicked off just in time, so there should be a low number of wip pacts, bar those that are failing because they have never been able to be successfully verified.

We follow TBD, and we're struggling with maintaining these pacts in branches 🙂

Feel free to elaborate on the particular pain points or struggles and we can see how we can help 🙂 sometimes another pair of ears and/or eyes is useful

It would be nice if there were an option where pending pacts are ignored (not verified) on the consumer main branch*,* if the provider has not yet implemented the required state(s). Once the relevant state(s) are added, the pact becomes actualized and enters the verification flow.

yes a combination of work in progress and pending pacts. the consumer will be blocked from deploying, until they have verified their contracts however on their main branch, as pact won’t be able to guarantee the pending contracts.