Hiya folks! I was looking for a bit of advise with...
# pact-broker
g
Hiya folks! I was looking for a bit of advise with webhooks, might be doing something silly. Part of my current process is: • PR against the provider tests against latest consumer Pacts tagged
main
(to ensure no regressions are being introduced) • Test results are published to Pact Broker • This triggers a webhook because
provider_verification_published
was fired ◦ The webhook is to set a “Pact verification” commit status check on GitHub • Because we’re checking against
main
, this updates the status of the HEAD commit Ultimately this means that my “Pact verification” status check on the main/HEAD commit reflects the last provider PR rather than the actual PR status. I have a few solution ideas: 1. Am I missing a webhook setting to only trigger when the provider build was tagged
main
?
That way I’d stop pushing commit statuses for PRs. 2. Should I not publish Pact results from PRs to the Broker? That would ensure it didn’t trigger the webhook, but would limit the amount of useful information in the Broker 3. Should I include the provider version in the GitHub commit status context? (e.g. so I have “Pact verification against main”, “Pact verification against {PR name}“) This will mean I have extra checks, potentially including failures from irrelevant provider PRs I’m erring towards the second option, but I think this is a slightly philosophical “how to use Pact” question so would be interested to hear what other users and maintainers think.
a
Disclaimer: I haven't been using Pact for a long time yet, so this might not be the best practice. I personally perform option 2. and don't publish anything from the provider CI when the pipeline trigger is a PR. I don't really see a reason to publish the results for it since at least in Azure the PR creates a temporary commit that will disappear from existence after the PR is abandoned/completed (hash won't be the same with the actual merge post-completion). For actual deployments I'm only interested in deployments recorded against
prod
or
develop
environments, so I feel I'm not losing any value by skipping the publishing for PRs. There was a
PACT_BROKER_PUBLISH_VERIFICATION_RESULTS
env variable that is already checked whether the run should publish a result or not, so I'm using that to skip the result publishing in my CI. Azure Pipelines:
Copy code
variables:
  publishPactResults: $[lower(ne(variables['Build.Reason'], 'PullRequest'))]

...
- task: Bash@3
  displayName: Run verification
  ...
  env:
    PACT_BROKER_PUBLISH_VERIFICATION_RESULTS: $(publishPactResults)
g
Thanks Akke, that’s a great explanation of the feeling I was getting. Seems like I set things up a bit too much when I did this initially 😄
👍 1
a
Experiment & learn 😄 By the way, there was the (rather) new
contract_requiring_verification_published
option that doesn't trigger the webhooks on each publish, but it does require some additional setup (docs). It has worked great for me to reduce the amount of test runs executed "unnecessarily".
g
Ooo, that sounds helpful. We’re not recording deployments/releases yet, but I’ll take another look when we are