GitLab CI

To use GitVersion with GitLab CI, either use the MSBuild Task or put the GitVersion executable in your runner's PATH.

Merge Request pipelines

In merge request pipelines GitLab sets CI_MERGE_REQUEST_REF_PATH (for example refs/merge-requests/15/head or refs/merge-requests/15/merge). GitVersion reads this variable through the GitLabCi build agent when it is present, following the same pass-through pattern as Azure Pipelines (BUILD_SOURCEBRANCH) and GitHub Actions (GITHUB_REF).

Branch resolution order in GitLabCi:

1. CI_COMMIT_TAG set — treat as a tag pipeline (GetCurrentBranch returns null)
2. CI_MERGE_REQUEST_REF_PATH set — use the merge request ref
3. otherwise — CI_COMMIT_REF_NAME (branch name)

After repository normalisation the friendly branch name becomes merge-requests/<iid>/head or merge-requests/<iid>/merge. Extend the pull-request branch configuration in GitVersion.yml so the regex matches GitLab's namespace (the default pull-requests|pull|pr pattern does not):

workflow: GitFlow/v1
branches:
  pull-request:
    regex: ^merge-requests/(?<Number>\d+)/(head|merge)$
    label: PullRequest{Number}

CI_COMMIT_REF_NAME still contains the source branch name (for example feature/foo) in MR pipelines; it is ignored when CI_MERGE_REQUEST_REF_PATH is set.

A working example of integrating GitVersion with GitLab is maintained in the project Utterly Automated Versioning

Here is a summary of what it demonstrated (many more details in the Readme)

• Is a reusable working example known as a Guided Exploration (Guided Exploration Manifesto) - so job logs and package artifacts can be reviewed. The project can also be imported to your own GitLab group or instance as a starting point for your own work.
• IMPORTANT: It demonstrates how to override GitLab CI's default cloning behavior so that GitVersion can do a dynamic copy. Selectively clones GitVersion.yml so that these settings take effect. This best practice demonstrates the best way to do this while avoiding a double-cloning of the project (once by GitLab Runner and once by GitVersion).
• Implements GitVersion as a CI/CD Extension that can be reused across many projects using includes.
• Implements GitVersion as a single job that runs the GitVersion container and passes the version number downstream into both pipeline and job level variables, which means...
• It can be used with ANY coding language, framework or packaging engine.
• Generates example packaged artifacts:
  • Two ways of building Sem Versioned NuGet packages (msbuild-ish and nuget.exe-ish) and uploads them and tests them from a GitLab NuGet Repository.
  • A Sem Versioned GitLab Generic Package
  • A Sem Versioned docker container and uploads to GitLab Container Registry.
• It creates a Sem Versioned GitLab Release and Git tag using the GitLab Release Cli and links the generic package as evidence.