Hi all, random question. When the webhook exists in both consumer and provider pipeline, how do you prevent an infinite loop of calling the webhook when the other pipeline is ran? one method I thought of was using a separate branch that does not include the webhook on the 'called' pipeline. However if its calling a separate branch it will be generating a contract that is not on master which may be old and not current. What is the best practice for this scenario?

Why would there be an infinite loop? Consumer publishes a contract (triggering provider verification) Provider verification runs …. triggering nothing

So the webhook to call the consumer should not be on the provider? What if you implement a change on the provider side? Would you look to compare what is uploaded to the broker for the consumer contract?

huh?

Ok that makes sense

When the provider runs the verification, it asks the broker what the relevant contract(s) are

Yeah that makes sense thanks

You’re welcome. I’d like to diagram this better, but it’s kinda hard to find a diagram that works for all the different CI practices that people already have

The most common use case for webhooks is to trigger a provider build every time a pact changes, and to trigger a consumer build every time a verification is published. So here it mentions triggering the consumer build from a verification being published i.e. the provider has changed. So should the webhook only exist from one perspective and not both?

you use webhooks to trigger provider verification tasks based on pact url, when a consumer contract changes

They’re different webhooks. Because the contract is written by the consumer, you might want to kick off the provider build (to verify the consumer’s contract). At this point you probably can’t deploy (if the contract is new). When the contract is verified, you might want to kick off the consumer deploy.

you run a verification task based on consumer version selectors when the provider changes (or doesn't change, just on commit) - this pulls back any contracts matching the selectors, we recommed deployedOrReleased true and matchingBranch true

and to trigger a consumer build every time a verification is published.

^ I think this is misleading. It should say “trigger a potential consumer deploy every time….” I see why you thought there was a circular dependency 😬

OK I read this whole thread, and was confused - but this exact point is the problem! I personally don’t like that framing, and wouldn’t recommend it myself. I personally wouldn’t trigger any consumer build related actions from webhooks. I think you’re better off publishing verification events to tools like Github for status checks to unblock PRs to say the consumer build is “mergeable” or “deployable”