Update pact_changed webhook to contract_requiring_verification_published

[bethesque]

Hey Yousaf. I was halfway through writing a list of what needed to change, and then I thought, no, it's better for you to work it out from the existing docs, so you know what gaps there are in the documentation.

The docs are here https://docs.pact.io/pact_broker/webhooks#using-webhooks-with-the-contract_requiring_verification_published-event

There are a couple of ways we could make sure the right commit of the provider is triggered. The first would be to trigger a build for the commit using the Github dispatches api https://docs.github.com/en/rest/actions/workflows#create-a-workflow-dispatch-event This means that the definition of the github workflow would be the one from that sha (I believe).

The other way would be to trigger the workflow of the head repository commit, but checkout the correct SHA using the ref from the checkout action https://github.com/actions/checkout#checkout-a-different-branch. This would, I believe, use the most recent definition of the workflow, but with the old codebase.

My gut feel is to go with the first approach, because it means that the workflow/codebase will be easier to reason about. I haven't tested this though, so I'm not confident about which workflow file gets used. Thoughts?

Also, once we've updated this one, we'll need to update all the repos 😬

[YOU54F]

Started looking at this and I think the make create_or_update_pact_changed_webhook command has been incorrectly setting the webhook with the consumer property set to the provider name.

https://github.com/pactflow/example-provider/blob/master/Makefile#L88

Good thing we are having a look :)

[YOU54F]

I think option 1 will use the workflow from that sha

option 2 will use the main branch sha, and workflow - but only checkout the repo code by reference (so we get the right codebase by sha)

we can show both options easily enough, I've opted for option 2, it is minimal uplift from the pact_changed GH workflow so shows a nice side by side comparison.

[bethesque]

Started looking at this and I think the make create_or_update_pact_changed_webhook command has been incorrectly setting the webhook with the consumer property set to the provider name.

Yes, you're right. Good pick.

[bethesque]

option 2 will use the main branch sha, and workflow - but only checkout the repo code by reference (so we get the right codebase by sha)

Option 2 has the benefit of being able to run the tests from a commit before the workflow existed. So that is probably is best.

[YOU54F]

Supported by #29

Will setup webhook and give it a whirl now

[YOU54F]

This consumer build on a feature branch with an expected failure are provider verification time was run

https://github.com/pactflow/example-consumer/actions/runs/3153394454

fails CID as expected as no verified pact, provider build is triggered via webhook and fails, publishing verification result.

Would be nice to setup CID on the consumer side to use the retry mechanism built in.

Only snag is the user.githubToken is out of date, there is a valid one here user.GithubActionTriggerBuildToken but want to keep it as user.githubToken in the Makefile as it will be in all the docs too.

[bethesque]

Yeah, all our tokens are out of date and need to be re-generated.