[Bug] BUILD_SOURCEBRANCH is assumed to be relevant

[TheConstructor]

In Azure DevOps (Server) the environment variable BUILD_SOURCEBRANCH will contain the branch of the repository that triggered the build (see documentation for Build.SourceBranch). For multi-repository builds there is no relation to the self ("main") repository, but

GitVersion/src/GitVersion.Core/BuildAgents/AzurePipelines.cs

Line 24 in 9623cc4

public override string? GetCurrentBranch(bool usingDynamicRepos) => Environment.GetEnvironmentVariable("BUILD_SOURCEBRANCH");

uses the value of the environment variable without verifying.

Expected Behavior

The variable should not be used in multi-repository builds, as it causes incorrect versions.

Actual Behavior

We build the dev-branch of our repo, but GitVersion thinks it should provide a version for main, as that is the branch in another repository, that triggered the build

Possible Fix

For us it would likely help to have a switch to disable the AzurePipelines-handling. It may be possible to use System.PullRequest.SourceBranch/System.PullRequest.TargetBranch when set, but even then GitVersion could be called for another repo/sub-module

Steps to Reproduce

1. Set-up a multi-repository build in Azure DevOps (Server) -> https://learn.microsoft.com/en-us/azure/devops/pipelines/repos/multi-repo-checkout?view=azure-devops
2. Define a trigger on one of the other repositories on at leas one branch named different from the default-branch of the repository containing the build-definition
3. Commit to the other repository into the branch you defined the trigger for
4. A build will run and BUILD_SOURCEBRANCH is set to the name of the branch in the other repository

Context

We use GitVersion to version our documentation and want to update the development-docs whenever a commit is pushed. The branch in the docs-repo is dev, while the branch-name in other repos might be master. In this case a non-pre-release-version is generated

Your Environment

Azure DevOps Server 2020 Update 1.2

[TheConstructor]

Following https://learn.microsoft.com/en-us/azure/devops/pipelines/repos/multi-repo-checkout?view=azure-devops#repository-details you would need to access resources.repositories['self'].ref. It could be possible to guide the user to create a certain environment variable from it and use that, if present, instead of BUILD_SOURCEBRANCH

A sample addition to the build YAML might be:

variables:
  # self-ref to be able to use instead of Build.SourceBranch in multi-repository-builds
  - name: 'repositories.self.ref'
    value: $[ resources.repositories['self'].ref ]

which is by default then available as the environment-variable REPOSITORIES_SELF_REF to all build-steps

[TheConstructor]

I would like a fix that allows both

• disable Azure Pipelines Handling -> allows to run GitVersion for some auxilary repository, ... whatever
• specify another environment-variable based on $[ resources.repositories['self'].ref ]

I would guess, that the second part of the is the one solving the common use-case, but the first allows to implement your scenario without wondering how you can remove all relevant environment-variables for the step involving GitVersion.

I don't currently see a solution were everything just works out-of-the-box.

It might thus be a good idea to check, if BUILD_SOURCEBRANCH could be accurate, and if that's unlikely (too many commits in between) print a warning to the user, so that one of the two fix-paths can be applied

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. After 30 days from now, it will be closed if no further activity occurs.

[TheConstructor]

This is still troubling our builds

[gmndaniel]

Is anyone planning on looking into it? We have a separate repo for all our YAMLs, so it's impossible to do a manual pipeline build with this bug, since it will always take the branch of the YAML itself, and not the repo which requires the versioning.

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. After 30 days from now, it will be closed if no further activity occurs.

[TheConstructor]

Not sure I will have time to fix this, but it's still relevant :(

[gmndaniel]

Not sure I will have time to fix this, but it's still relevant :(

I found a workaround that seems to work on CI builds, and on manual runs.
I don't use the GitVersion task, but instead run a PowerShell script:

$workDir = "/path/to/src"
$env:BUILD_SOURCEBRANCH = $null
dotnet-gitversion "$workDir" /output json /output buildserver

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. After 30 days from now, it will be closed if no further activity occurs.