[Bug] Building from tag fails to produce correct version on Azure DevOps #2231
Labels
Comments
|
I tried to reproduce in a integration test, but it just passes. Tried several things, but I think the Azure part of this is not sticking, despite trying to follow one of the existing tests? Hopefully it gives an idea though? [Test]
public void AlanTargetBranchTagDoesNotWork()
{
//var targetBranch = "refs/heads/release/ProdName/v6.9";
//var targetBranch = "refs/tags/ProdName/v6.9.2";
var targetBranch = "release/ProdName/v6.9"; // works
var tagBranch = "tags/ProdName/v6.9.2";
Commit commit = null;
using var fixture = new RemoteRepositoryFixture(
path =>
{
Repository.Init(path);
Console.WriteLine("Created git repository at '{0}'", path);
var repo = new Repository(path);
repo.MakeCommits(5);
repo.CreateBranch(targetBranch);
Commands.Checkout(repo, targetBranch);
repo.MakeCommits(5);
commit = repo.MakeACommit();
repo.ApplyTag("v6.9.2");
return repo;
});
var gitVersionOptions = new GitVersionOptions
{
WorkingDirectory = fixture.LocalRepositoryFixture.RepositoryPath,
RepositoryInfo =
{
TargetBranch = tagBranch,
CommitId = commit.Sha
},
Settings =
{
NoNormalize = false,
NoFetch = false
}
};
var options = Options.Create(gitVersionOptions);
var environment = new TestEnvironment();
environment.SetEnvironmentVariable(AzurePipelines.EnvironmentVariableName, "true");
environment.SetEnvironmentVariable("BUILD_SOURCEBRANCH", tagBranch);
var sp = ConfigureServices(services =>
{
services.AddSingleton(options);
services.AddSingleton<IEnvironment>(environment);
});
var gitPreparer = sp.GetService<IGitPreparer>();
gitPreparer.Prepare();
fixture.AssertFullSemver("6.9.2");
fixture.AssertFullSemver("6.9.2", repository: fixture.LocalRepositoryFixture.Repository, commitId: commit.Sha, targetBranch: tagBranch);
} |
|
It's the same issue. #2074 started with building on TeamCity, and this one is Azure DevOps. In both cases, the root issue is that building from a tag from a detached head triggers the normalization, then the following build ends up generating a weird version name. |
|
Closing as duplicate of #2074 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the bug
When building in Azure DevOps, recently we've been getting some strange version numbers from GitVersion. We follow ReleaseFlow, and it's mostly working for us normally. We do feature branches and merge to master. Every so often when we are ready to release to customers, we branch a release branch "release/ProdName/v6.9". Builds here look like "6.9.2-rc.220" until we decide to git tag, at which point we get 6.9.2 as expected.
Recently though, we've been getting builds like "6.10.0-tags-ProdName-v6-9-2.1+220" instead. We couldn't work out what was going on or what was causing. It seemed to only be affecting one product within the monorepo at first, and removing and recreating the release branch seemed to have fixed it.
We now see it again, but I've noticed today that it's tied to the build trigger. If I trigger a build on the branch release/ProdName/v6.9, where the latest commit is tagged "ProdName/v6.9.2", I'll get the expected result of a version 6.9.2. If instead I trigger a build on the tag, it builds the exact same commit but gives a version 6.10.0-tags-ProdName-v6-9-2.1+220
Expected Behavior
Version 6.9.2
Actual Behavior
Version 6.10.0-tags-ProdName-v6-9-2.1+220
Possible Fix
Found in the GitVersion source that the part "Branch from build environment: xxx" comes from the Azure Pipelines env variable BUILD_SOURCEBRANCH. In each build, the git checkout is actually the same, and specifies only the commit, no branches. On the tag one it's refs/tags/ProdName/v6.9.2 and this then results in "No branch configuration found for branch tags/ProdName/v6.9.2
My understanding is that a tag on a commit should always override any branch info, but that doesn't seem to be happening.
Steps to Reproduce
As above, trigger build from release branch, or from tag. In both cases the commit being built is the same, all steps are the same.
Agent parameters are same.
Git commands run by Azure DevOps are the same. Tag is present in both. Commit is the same.
Tag build says:
Git step title in Azure Devops is "Checkout RepoName@refs/tags/ProdName/v6.9.2 to s"
command used is >git checkout --progress --force 24257159c4cf9db433be7c50fa12b38d670834c2
sourceBranch=refs/tags/ProdName/v6.9.2
Finishing: Checkout RepoName@refs/tags/ProdName/v6.9.2 to s
Release branch build says:
Git step title in Azure Devops is "Checkout RepoName@release/ProdName/v6.9 to s"
command used is >git checkout --progress --force 24257159c4cf9db433be7c50fa12b38d670834c2
sourceBranch=refs/heads/release/ProdName/v6.9
Finishing: Checkout RepoName@release/ProdName/v6.9 to s
After the checkout step, a powershell script is run with following
"GitVersion.exe /output buildserver /nofetch"
Tag build produces this:
Release branch build produces this:
I tried but can't reproduce this locally because it's tied to the buildserver code.
Branch from build environment: refs/tags/ProdName/v6.9.2coming from the environment variables on Azure DevOps.I'm looking at reproducing in a integration test, but not sure exactly how.
It is similar to issue #2206 but without timing or process discussion. Seems only related to Azure DevOps environment.
Context
When building in Azure DevOps, recently we've been getting some strange version numbers from GitVersion. We follow ReleaseFlow, and it's mostly working for us normally. We do feature branches and merge to master. Every so often when we are ready to release to customers, we branch a release branch "release/ProdName/v6.9". Builds here look like "6.9.2-rc.220" until we decide to git tag, at which point we get 6.9.2 as expected.
Recently though, we've been getting builds like "6.10.0-tags-ProdName-v6-9-2.1+220" instead. We couldn't work out what was going on or what was causing. It seemed to only be affecting one product within the monorepo at first, and removing and recreating the release branch seemed to have fixed it.
Your Environment
GitVersion.yml
The text was updated successfully, but these errors were encountered: