Hi folks, A question on achieving Pact Nirvana with pending pacts. When provider CI runs, there are two cases - main branch or PR branch. On main branch (we use go lingo) we have: • EnablePending = true • IncludeWIPPactsSince = wipPactsSinceDate() // returns reasonable date • and we obviously publish the results Question on the PR branch we have questions: • IncludeWIPPactsSince - we have this unset, because consumers can have tons of PRs and idk if we want every provider PR build to verify against every consumer PR build, but this might be premature optimization • EnablePending - this one I'm confused about. We don't want provider PR build to fail because of a pending consumer pact; but we also don't want provider PR build to be the first one to mark the consumer contract as non-pending, by publishing first verification result to the broker (because as I understand this, first verification => no longer pending?) • with the above in mind, maybe we shouldn't be publishing verification results from the provider branch? we invoke

can-i-merge

after running both consumer and provider tests though, and if we don't publish results, idk if that's gonna work correctly? Thanks!

Hey Vlad 1. wip is recommended to be scoped to your main branch https://docs.pact.io/provider/recommended_configuration#work-in-progress-pacts 2. a pending pact, would be verified only for that branch, and any newly created branches. it would be unverified for the main branch. see bold section https://docs.pact.io/pact_broker/advanced_topics/pending_pacts#how-it-is-calculated 3. i would always publish provider verifications on provider verifications triggered by web-hooks for a single pact req verification from consumer, or for dynamically fetched pacts if the provider makes a change ( there should be two distinct provider jobs or the ability to switch modes if provided a pact url to verify)

Thanks! so do you recommend publishing verification results from when we're building a provider PR?

yes, that would record that the provider feature branch and ergo implementation is compatible or not with its consumer expectations at the point in time, dependant on the consumer version selectors. if you run can i deploy or can i merge checks on the pr, you then have a verification result to reference for that version or provider ( github or similar vcs checks are nice in pull request UI’s )

Awesome, thanks. We just merged a change in our shared provider testing framework to enable pending on PR builds based on this thread — was hardcoded to

false

before. Here's our current setup at a glance, is it ok to ask you to see if anything looks off? 🙂 Provider PR branch builds: •

EnablePending = true

(new — was

false

) •

IncludeWIPPactsSince = nil

(WIP stays main-only, per your rec) • Publish verification results: yes • Provider branch: actual PR branch name • Version: unique

<semver>-<git-sha>

label Provider main / release branch builds: •

EnablePending = true

• `IncludeWIPPactsSince`: ~90 days back • Publish verification results: yes • Provider branch: actual branch name • Version: just

<semver>

Consumer PR branch builds: • Publish pact: yes • Consumer branch: actual PR branch name • Version: unique

<semver>-<git-sha>

label Consumer main branch builds: • Publish pact: yes • Consumer branch: actual branch name • Version: just

<semver>

Webhook-triggered provider builds (single pact URL from a consumer change): separate code path, verifies just that one pact and publishes.

that looks excellent, scoped wip to 90 days on main is ideal. i question why only semver in main/release for provider specifically. less concerned on consumer side when a webhook triggered build occurs, multiple webhooks should occur for recorded versions on main branch, and deployed/released to environments, deduped if version is the same the webhook contains a commit sha extracted from the version if necessary which can be used to checkout the local provider codebase, to the corresponding deployed/released/main version of code ( the latter traditionally just head of the default branch ) if your semver version only can point you to the deployed/released code, that is also sufficient, you just to ensure the webhook triggered job takes this into account this fills out the consumer verification for a pact requiring verification against head of provider default branch, and all deployed/released versions, ensuring they have a completed matrix to query with CID ref - https://docs.pact.io/pact_broker/webhooks#using-webhooks-with-the-contract_requiring_verification_published-event

our semvers are git tags and are immutable, so they're == commit sha, and our webhook passes that information. Thanks!

spot on, sounds like you are at Pact Nirvana 🙌🏾

sweet! 🙂 thanks for sanity checking our setup ❤️

any time buddy

Thanks for your inputs here Yousaf - and for sharing what you’ve been up to Stan!

Yeah, would be great to chat at some point, although I think you overestimate how mature our contract-testing ecosystem is 🙂 tbh our pact adoption is still lacking, so while we have integrated it in CI well enough, we are still learning how to use more advanced features, and are working to get traction across teams. Pact is by its nature a new and somewhat complex concept, but now with AI we're hoping we can create pact skill (following the skills you guys published) and hope this will ease the adoption process.

Another option is to jump in to our fortnightly maintainer meet. It's pretty casual and would love to say hi. Next one 27th May

yeah, that sounds like fun 🙂

FYI the calendar invite/link is here: https://github.com/pact-foundation/roadmap#-maintainer-sessions The link is also available in #C05HCLA3C93 Hope to see you then!

thanks, I'll try, but might have to skip this one depending on family stuff 🙂

no probs