Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

contract_requiring_verification_published webhook - should it trigger on first publication #574

Open
YOU54F opened this issue Oct 6, 2022 · 6 comments

Comments

@YOU54F
Copy link
Member

YOU54F commented Oct 6, 2022

RE: contract_requiring_verification_published webhook.

For a brand new integration

  • both consumer and provider are pre-created and have mainBranch property set (The emergent behaviour is the same, whether step is conducted or not)
  • contract_requiring_verification_published webhook is pre-created and enabled

When a new pact file is published, with the branch property, and not the tag property, on the main branch

Expected behaviour:- contract_requiring_verification_published event is triggered, so provider build is triggered against the latest pact requiring verification on the branch, mainBranch property is set to main

Actual behaviour:-

Created frontend version dd4c62cbcefa2c3e4897028e57135844052a3dfe with branch main
Pact successfully published for frontend version dd4c62cbcefa2c3e4897028e57135844052a3dfe and provider clients-service.
  View the published pact at https://saflow.pactflow.io/pacts/provider/clients-service/consumer/frontend/version/dd4c62cbcefa2c3e4897028e57135844052a3dfe
  Events detected: contract_published, contract_content_changed (first time untagged pact published)
  No enabled webhooks found for the detected events
  Next steps:
    * Add Pact verification tests to the clients-service build. See https://docs.pact.io/go/provider_verification

contract_content_changed event is triggered with note (first time untagged pact published)

This means that the contract_content_changed and contract_requiring_verification_published are currently not equivalent and the provider build using consumer version selectors needs to be retrieved.

The mainBranch property is set to main (the git branch in the repo) after uploading the pact file, the consumer version selectors mainBranch: true pick up the pact and validate it, but only after manually triggering the build.

if the pact was uploaded with a tag and the pact_changed webhook was setup, this would have triggered the pact URL driven provider build

Additional question - Is the main branch property automatically set in the first instance if it is main or master? If one was to start on a feature branch, and

@bethesque
Copy link
Member

Do any versions exist on the main branch for the provider at this stage?

@YOU54F
Copy link
Member Author

YOU54F commented Oct 6, 2022

no provider build in this scenario has never run,

https://github.com/YOU54F/contract-test-nirvana/actions

@bethesque
Copy link
Member

Yup, the reason it doesn't trigger is that it doesn't know the version to trigger for because there are no version numbers in the database. We've had a discussion about using HEAD as the default when this happens, but I haven't done any coding for it yet. It would be a quick piece of work to do.

@bethesque
Copy link
Member

@YOU54F
Copy link
Member Author

YOU54F commented Oct 6, 2022

expectation is from this note

https://docs.pact.io/pact_nirvana/notes_1

If you want to pre-create the "pact changed" webhook for providers so that the first time a consumer publishes a pact, the webhook is immediately triggered, you can use the following commands in your pipeline

however it doesn't suggest that the provider in that scenario has never run.

ahh, interesting thanks for that Beth

@YOU54F
Copy link
Member Author

YOU54F commented Oct 6, 2022

If it did fire, it wouldn't be hard from the provider side build to implement logic to checkout the HEAD of the main branch, if the sha property in the webhook isn't there, as it will report the commit sha and branch back when publishing results

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants