Prerequisites
GitVersion package
GitVersion.Tool
GitVersion version
6.6.1
Operating system
Linux
What are you seeing?
In GitLab Merge Request pipelines, GitVersion resolves the build branch from CI_COMMIT_REF_NAME (the source branch name, e.g. developer or feature/foo) and ignores CI_MERGE_REQUEST_REF_PATH (e.g. refs/merge-requests/15/head).
The GitLab runner correctly checks out detached HEAD at refs/merge-requests/<iid>/head; only GitVersion's branch resolution is wrong.
What is expected?
When CI_MERGE_REQUEST_REF_PATH is set, GitLabCi.GetCurrentBranch() should return that ref (pass-through), with precedence:
CI_COMMIT_TAG → null (tag pipeline)
CI_MERGE_REQUEST_REF_PATH → merge request ref
CI_COMMIT_REF_NAME → branch name
This matches how other agents pass platform refs unchanged (Azure BUILD_SOURCEBRANCH, GitHub GITHUB_REF).
After repository normalisation, the friendly branch name should be merge-requests/<iid>/head or merge-requests/<iid>/merge, allowing pull-request configuration to apply when the user extends the regex for GitLab's namespace:
branches:
pull-request:
regex: ^merge-requests/(?<Number>\d+)/(head|merge)$
Implementation should stay in GitVersion.BuildAgents only — no GitLab-specific logic in Core.
Steps to Reproduce
- Create a GitLab project with a
GitVersion.yml using default GitFlow and a pull-request branch configuration.
- Open a Merge Request (e.g.
developer → main).
- Run a pipeline job on the MR pipeline:
gitversion:
rules:
- if: $CI_MERGE_REQUEST_IID
image: gittools/gitversion:6.6.1
script:
- dotnet-gitversion . /verbosity Diagnostic /l console /output json
- Observe that
CI_MERGE_REQUEST_REF_PATH is set, but GitVersion logs Branch from build environment: <source-branch>.
References
RepositoryFixture Test
No response
Output log or link to your CI build (if appropriate).
Prerequisites
GitVersion package
GitVersion.Tool
GitVersion version
6.6.1
Operating system
Linux
What are you seeing?
In GitLab Merge Request pipelines, GitVersion resolves the build branch from
CI_COMMIT_REF_NAME(the source branch name, e.g.developerorfeature/foo) and ignoresCI_MERGE_REQUEST_REF_PATH(e.g.refs/merge-requests/15/head).The GitLab runner correctly checks out detached HEAD at
refs/merge-requests/<iid>/head; only GitVersion's branch resolution is wrong.What is expected?
When
CI_MERGE_REQUEST_REF_PATHis set,GitLabCi.GetCurrentBranch()should return that ref (pass-through), with precedence:CI_COMMIT_TAG→null(tag pipeline)CI_MERGE_REQUEST_REF_PATH→ merge request refCI_COMMIT_REF_NAME→ branch nameThis matches how other agents pass platform refs unchanged (Azure
BUILD_SOURCEBRANCH, GitHubGITHUB_REF).After repository normalisation, the friendly branch name should be
merge-requests/<iid>/headormerge-requests/<iid>/merge, allowingpull-requestconfiguration to apply when the user extends the regex for GitLab's namespace:Implementation should stay in
GitVersion.BuildAgentsonly — no GitLab-specific logic in Core.Steps to Reproduce
GitVersion.ymlusing default GitFlow and apull-requestbranch configuration.developer→main).CI_MERGE_REQUEST_REF_PATHis set, but GitVersion logsBranch from build environment: <source-branch>.References
CI_MERGE_REQUEST_REF_PATH:refs/merge-requests/<iid>/heador/mergeAzurePipelines.GetCurrentBranch()(BUILD_SOURCEBRANCH),GitHubActions.GetCurrentBranch()(GITHUB_REF)RepositoryFixture Test
No response
Output log or link to your CI build (if appropriate).