Pact Foundation

I'm working on using the providerVersionBranch and providerVersionNumber for webhooks, so we can validate all deployed provider environments when a consumer updates a contract. The issue I'm having is that in gitlab, I can't check out a commit, I need to have either a branch or tag name.  When recording deployments, it seems that we are only recording the version number (which I think is a commit). It is unclear to me how to associate a branch with that version number.

&gt; in gitlab, I can’t check out a commit
really? is that a constraint of GitLab itself, or just the way it’s configured? Is that because GitLab doesn’t do a clone of the repository?

Presumably your CI build itself could do a `git checkout &lt;commit&gt;` even if GitLab won’t do it automatically?

I don’t think we retain a mapping of versions to branches you can query, but I’ll check

I tried `git checkout &lt;commit&gt;`, and `git fetch` and then `git checkout &lt;commit&gt;` and got an error (only in some cases, such as the commit not being on the main branch), even though the same thing worked locally.  I will investigate further. I saw <https://stackoverflow.com/questions/63454536/build-manual-gitlabci-pipeline-job-using-specific-commit-id|this> on stackoverflow which referenced this open <https://gitlab.com/gitlab-org/gitlab/-/issues/22886|issue>.

If I'm the only person with this issue, I'm probably doing it wrong

I saw this comment on <https://gitlab.com/gitlab-org/gitlab/-/issues/22886|this open issue>:
&gt; This feature would be very useful for integrating with Pact, where for full Pact integration, you need to be able to re-run a GitLab CI/CD job for a specific commit hash that Pact provides, via a webhook. I'm wondering if a reasonable workaround would be to create a tag with the commit hash as part of the pipeline when it first runs, then Pact could re-trigger the job using that tag as the ref?


Another approach, if it’s useful, is to not just use _only_ the commit SHA as the version identifier, but include other bits - such as the tag/branch (e.g. a <https://semver.org/|semver> compatible thing. This <https://www.npmjs.com/package/absolute-version|tool> was written by an ex Pact Maintainer you might find helpful). Then in the build job, you could destructure the version into its parts?

I am not sure what the issue was, but as long as our commits are relatively recent from mainline, checking them out inside our gitlab pipeline seems to work fine.

Nice! A lot of CI tools do a shallow check-out, or don’t pull new commits. Sometimes a clean CI agent is all you need