Hi! I want to migrate to use

contract_requiring_verification_published

in the Pact-Broker's webhooks as I am working on multiple environments (main branch, integration, stage, prod). I am using Gitlab trigger tokens which trigger a pipeline only running the

pactVerify

job (which is a Gradle talk of my project executing the Java PactProviderTest). As Gitlab only accepts branches and tags as reference (

ref

), I don't know how I can pass the right revision to the

ref

as my

pactbroker.providerVersionNumber

returns a combination of my Gradle project version + the respective Git short SHA (e.g. 1.0.0-a6d33b7a). My tags in Gitlab are named in format v1.0.0. I was thinking about parsing the version and do string manipulation to reach my desired format, but this seems not be possible within a webhook. Alternatively I thought about setting the

providerVersionsTags

and use them to pass to the

ref

. But this seems to be a complex (and probably dirty) workaround which I am not even sure about if it would work as expected. Do you have any idea?

I don't know about your git workflow, but if all your versions deployed in integration stage and prod environnement are tagged then you should modify your Pact Verifier so that when publishing verification results from the CI it sets your tag (gitlab-ci env var = $CI_COMMIT_TAG) as your provider branch. Then you can use pactbroker.providerVersionBranch as your ref in webhooks and it will trigger the verification on the right commit worked for me

Hmm interesting idea. Thanks for the quick reply! But I wonder if there will be webhooks triggered for each environment as it is done with versions. Do you know if there is any difference? Also I have to think it through as we are also working with feature branches and even a service which is a provider and a consumer at the same time. I wonder if the fact that the branch name information would get lost might cause issues...

yes webhooks are triggered for each environment with the right branch/tag. But yeah with your workflow I don't know. I suppose It could work if you have a specific pipeline for tags that deploy to various env and also be consistent with the branch naming when publishing and verifying About 'providerVersionsTags' I'll let someone from pact confirm it but I think tags is bound to be dropped

Hi Adrien, sorry for the late reply. In the meantime we tried some stuff and I guess it could work with putting tags into the branch variable. Currently we are not running our deployment jobs on tag pipelines but on the main, which means that we have to run the Pact-related jobs after the tag creation (and also the release of artefacts) in order to be able to assign the correct tag to the new Pact contract version. As long as we do not deploy the artefacts when the Pact contract breaks, it should be fine. But we are currently using the

can-i-merge

function before we are merging the feature branches into the main pipeline. This we could not use anymore since we don't have main branches tagged, which the

can-i-merge

would check against, but only tags. But as we are directly deploying to integration environment after the tag has been published, we wouldn't really need that functionality anyways. Or what do you think? Checking

can-i-deploy

three times (integration, stage, prod) should be good enough? As an alternative we thought about creating a second tag in Gitlab which equals the pact pacticipant version so that instead of the branch variable, we could just send the

pactbroker.providerVersionNumber

to the Gitlab trigger token

ref

...