Hello! :wave: I have a question about Provider Ver...
# general
s
Hello! 👋 I have a question about Provider Verification and CI/CD workflow. Context/Setup: • We have an integration between Consumer and Provider. • When Consumer changes the contract, Pact Broker triggers Provider Verification Job • Provider Verification Job pulls master, runs the tests with new pact, reports back the results • In the meantime, Consumer job polls the results with can-i-deploy with staging and prod environments Situation: • Consumer adds a field to "given" block, aka the Provider State - This changes the Contract • Consumer CI runs, pact sees the change, triggers Provider Verification Job • Provider pulls master, runs the tests, and they succeed, because the new given field is not yet extracted/used Current outcome: • Provider Verification results are sent to broker • Consumer CI/CD polls the results with can-i-deploy, but sees that only prod/master is verified, but staging has no verified pact • Consumer CI/CD is red I followed the Pact Nirvana CI/CD setup where it suggested to make provider verification check with master/main branch. I do not remember there being an exact reasoning for this. We're now thinking, should it also check for other environments? Why, and why not? Am I missing something here?
Also if we do a backwards compatible change here and move provider changes up first: • On provider side, add support for the new provider state in given block • Merge provider to master • Run Consumer CI/CD Would the provider verification logic be any different? I mean from consumer PoV, it still validates against master and the contract changes, so it does not really care how the provider sets up its state... Then the can-i-deploy would still fail, as the beta is still not verified
when you use this webhook, it fires requires for each of the provider versions that need to be verified. If you always verify main/master, then you won’t build the verification matrix needed to allow this situation. You should adjust the build to checkout the correct version that is specified in the webhook
s
Ah, that makes sense... One thing though. In the docs link you shared, there is an example for Travis CI, which has branch and sha in the "request" field. I assume this example is a portion of the webhook. We are using jenkins, so until now, we provided the pact url, branch and commit in the query params of the url. Checking the pact broker API - Webhook, I don't see there being a
branch
and
sha
fields under the
request
. Do we just use the
pactbroker.providerVersionBranch
and
pactbroker.providerVersionNumber
variables now inside the "url" field that we pass and it should work? • We tried that, and it technically did work, as it now used the version instead of "HEAD" for the provider version, and it somehow now linked it together for also other environments. BUT, it did not still fire a request for each environment, so I'm sceptical how it worked. • I'm interested in what is the logic within pact broker to determine which branches to run it for.
m
The webhook logs should explain what it's doing. If the same version is deployed to multiple environments and is the main branch, only one will be fired (i.e. it deduplicates them)
s
Okay, this sounds fair. Thank you for explaining this.