[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.

[HHobeck]

Hi there.

I'm not sure if this is a bug or an improvement issue. Anyway I see that the behavior is conflicting with the feature of multi-repository build in Azure DevOps. The BUILD_SOURCEBRANCH variable like you mentioned is used to determine the current branch and is highly related to AzurDevOps.

Might it be an idea to us an arbitrary environment variable with the name e.g. GIT_BRANCH which will be used instead of the pipeline specific variable name if it exists? I think it would be not so hard to implement. I'm not sure if GIT_BRANCH is arbitrary because I have seen it in other pipelines already.

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

@arturcic what do you think?

Regards

[asbjornu]

@HHobeck, GIT_BRANCH is already in use by the Jenkins and TeamCity build agents:

GitVersion/src/GitVersion.BuildAgents/Agents/TeamCity.cs

Line 40 in 0ff62cc

public override bool PreventFetch() => !string.IsNullOrEmpty(Environment.GetEnvironmentVariable("Git_Branch"));

GitVersion/src/GitVersion.BuildAgents/Agents/Jenkins.cs

Line 26 in 0ff62cc

: Environment.GetEnvironmentVariable("GIT_LOCAL_BRANCH") ?? Environment.GetEnvironmentVariable("GIT_BRANCH");

I think, however, that it is a good variable for us to default to, since affaict, its semantics would be the same as its current implementation.

[arturcic]

@HHobeck, GIT_BRANCH is already in use by the Jenkins and TeamCity build agents:

GitVersion/src/GitVersion.BuildAgents/Agents/TeamCity.cs

Line 40 in 0ff62cc

public override bool PreventFetch() => !string.IsNullOrEmpty(Environment.GetEnvironmentVariable("Git_Branch"));

GitVersion/src/GitVersion.BuildAgents/Agents/Jenkins.cs

Line 26 in 0ff62cc

: Environment.GetEnvironmentVariable("GIT_LOCAL_BRANCH") ?? Environment.GetEnvironmentVariable("GIT_BRANCH");

I think, however, that it is a good variable for us to default to, since affaict, its semantics would be the same as its current implementation.

I think there was a draft PR @asbjornu was working on related to the GIT_BRANCH

[arturcic]

#3049

[arturcic]

🎉 This issue has been resolved in version 6.0.0-beta.6 🎉
The release is available on:

• GitHub Release
• Chocolatey Package
• .Net Global Tool

Your GitReleaseManager bot 📦🚀