[BUG] GitVersion calculating wrong version when building a tag #2074
Comments
|
If you define the environment variable |
|
It doesn't look like it, no. If I remote into the build agent and run gitversion there, then it too produces the unexpected values. However, I did notice that if I try to build the tag directly then it give me the incorrect version numbers, but if I build the So is that a bug in GitVersion, or a bug in how am I using it with Git and TeamCity? |
|
Not sure. Are you able to reproduce the problem in a |
|
I too see this (or a similar) problem on AppVeyor. I'm also able to reproduce it by checking out the tag locally. I expected the version to be v1.14.3, but instead it becomes v1.15.0. |
|
I am also seeing this with version 5.1.3. It seems to be a regression, as it works correctly in 5.1.2. |
|
It would be interesting to find which commit or PR introduced this change, because it means we don't have tests that cover this use-case, again meaning the fact that this used to work might have been more by accident than by explicit design. I agree that checking out a tagged commit should give the build the version number of the tag, though. A PR with a |
|
I can confirm that this is happening on Azure DevOps with GitVersion.Tool 5.2.4 as well. I tried to reproduce it locally and I can when I do exactly what Azure DevOps does: Then I run GitVersion using the dotnet tool: Output: However! If I remove the environment variable |
|
The Fix for #1743 introduced a check wherein if the tagged version is semantically less than the pre-release version, it will use the pre-release version instead. This normally wouldn't trigger, except that when the detached head is normalized by the build server code, it will create a branch called This is ONLY an issue if your build automation triggers on the tag creation and tries to build the tag directly, not when you build the commit directly. The difference is the setting of the source branch through the environment variable, that then gets picked up by the build server adapter, overriding the current branch name. |
|
I was trying to reproduce it in testing, but I'm not exactly sure how to model it. I can reproduce it like this: If you want to try it again, you need to do: to reset the setup so normalize will do its thing again. I'm willing to work to setup a repro, but could use some advice on how to model it. |
|
A reproduction! Awesome, @garoyeri! That looks like something that should be possible to reproduce in code, no? Have you tried reproducing the problem in a |
|
I tried to do [Test]
public void ShouldGenerateTaggedVersionInBuildAutomation()
{
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.ApplyTag("1.0.1");
repo.MakeCommits(5);
var commit = repo.MakeACommit();
repo.ApplyTag("1.0.2");
Commands.Checkout(repo, commit.Sha);
return repo;
});
GitRepositoryHelper.NormalizeGitDirectory(new NullLog(), new TestEnvironment(), fixture.LocalRepositoryFixture.RepositoryPath,
new AuthenticationInfo(), noFetch: true, currentBranch: "refs/tags/1.0.2", isDynamicRepository: false);
fixture.AssertFullSemver("1.0.2", targetBranch: "tags/1.0.2");
fixture.AssertFullSemver("1.0.2", repository: fixture.LocalRepositoryFixture.Repository, targetBranch: "tags/1.0.2");
}Am I doing something wrong with the test setup or assertion? |
|
Basically, I need to make a detached head, let the normalize happen, then try to calculate a version. |
|
Hm, yeah. Are you able to invoke a normalization in the test? |
|
I called the Normalization from the test (see the code above). But I suspect my real issue is in how I invoke the assertion, it seems to "fix" things by the time it generates a version number. Does my test code accurately create a detached head situation that we're talking about here? And does my assertion simulate building from a tag? I'm not entirely sure because I'm not familiar with the testing helpers. |
|
Ah yes, I see now. I will have to do some debugging myself to see whether the provided test behaves the way we need it to or not. |
|
I've seen a similar bug to this myself, but when it surfaced my manual normalization of the Git repository didn't work because |
|
Can you confirm whether the tag that initiated the build was available, @rose-a? |
|
Affirmative! GitHub seems to checkout the tag itself... |
arturcic
changed the title
|
Strange... worked perfectly on the next tag... Resolved version info: {
"Major":3,
"Minor":0,
"Patch":3,
"PreReleaseTag":"",
"PreReleaseTagWithDash":"",
"PreReleaseLabel":"",
"PreReleaseNumber":"",
"WeightedPreReleaseNumber":"",
"BuildMetaData":"",
"BuildMetaDataPadded":"",
"FullBuildMetaData":"Branch.tags-v3.0.3.Sha.29407e0d5b38f315333644d187d103cabed01822",
"MajorMinorPatch":"3.0.3",
"SemVer":"3.0.3",
"LegacySemVer":"3.0.3",
"LegacySemVerPadded":"3.0.3",
"AssemblySemVer":"3.0.3.0",
"AssemblySemFileVer":"3.0.3.0",
"FullSemVer":"3.0.3",
"InformationalVersion":"3.0.3+Branch.tags-v3.0.3.Sha.29407e0d5b38f315333644d187d103cabed01822",
"BranchName":"tags/v3.0.3",
"EscapedBranchName":"tags-v3-0-3",
"Sha":"29407e0d5b38f315333644d187d103cabed01822",
"ShortSha":"29407e0",
"NuGetVersionV2":"3.0.3",
"NuGetVersion":"3.0.3",
"NuGetPreReleaseTagV2":"",
"NuGetPreReleaseTag":"",
"VersionSourceSha":"29407e0d5b38f315333644d187d103cabed01822",
"CommitsSinceVersionSource":15,
"CommitsSinceVersionSourcePadded":"0015",
"CommitDate":"2020-04-19"
} |
|
That is very weird, indeed. |
|
I just noticed that having moved that repo from GitFlow to GitHubFlow between |
|
Here's a log for a GitHub Actions build for https://gist.github.com/wjrogers/45a7c8699c36fd429a864906bcd6fe95 |
|
Maybe it is related, I am also running it in a build agent and I a get different PreReleaseNumber running gitversion on my workstation. Local gitversion v5.1.3 produces: {
"Major":1,
"Minor":2,
"Patch":0,
"PreReleaseTag":"alpha.172",
"PreReleaseTagWithDash":"-alpha.172",
"PreReleaseLabel":"alpha",
"PreReleaseNumber":172,
"WeightedPreReleaseNumber":172,
"BuildMetaData":"",
"BuildMetaDataPadded":"",
"FullBuildMetaData":"Branch.develop.Sha.2207f42429e92f104978eadf8d37e233e5dfa455",
"MajorMinorPatch":"1.2.0",
"SemVer":"1.2.0-alpha.172",
"LegacySemVer":"1.2.0-alpha172",
"LegacySemVerPadded":"1.2.0-alpha0172",
"AssemblySemVer":"1.2.0.0",
"AssemblySemFileVer":"1.2.0.0",
"FullSemVer":"1.2.0-alpha.172",
"InformationalVersion":"1.2.0-alpha.172+Branch.develop.Sha.2207f42429e92f104978eadf8d37e233e5dfa455",
"BranchName":"develop",
"Sha":"2207f42429e92f104978eadf8d37e233e5dfa455",
"ShortSha":"2207f42",
"NuGetVersionV2":"1.2.0-alpha0172",
"NuGetVersion":"1.2.0-alpha0172",
"NuGetPreReleaseTagV2":"alpha0172",
"NuGetPreReleaseTag":"alpha0172",
"VersionSourceSha":"fb4e61aaa34536a093b55c39017dfaceec400866",
"CommitsSinceVersionSource":172,
"CommitsSinceVersionSourcePadded":"0172",
"CommitDate":"2020-08-27"
}In the build agent GitVersion.Tool/5.3.7/x64/dotnet-gitversion produces: {
"Major":1,
"Minor":2,
"Patch":0,
"PreReleaseTag":"alpha.159",
"PreReleaseTagWithDash":"-alpha.159",
"PreReleaseLabel":"alpha",
"PreReleaseNumber":159,
"WeightedPreReleaseNumber":159,
"BuildMetaData":"",
"BuildMetaDataPadded":"",
"FullBuildMetaData":"Branch.develop.Sha.2207f42429e92f104978eadf8d37e233e5dfa455",
"MajorMinorPatch":"1.2.0",
"SemVer":"1.2.0-alpha.159",
"LegacySemVer":"1.2.0-alpha159",
"LegacySemVerPadded":"1.2.0-alpha0159",
"AssemblySemVer":"1.2.0.0",
"AssemblySemFileVer":"1.2.0.0",
"FullSemVer":"1.2.0-alpha.159",
"InformationalVersion":"1.2.0-alpha.159+Branch.develop.Sha.2207f42429e92f104978eadf8d37e233e5dfa455",
"BranchName":"develop",
"EscapedBranchName":"develop",
"Sha":"2207f42429e92f104978eadf8d37e233e5dfa455",
"ShortSha":"2207f42",
"NuGetVersionV2":"1.2.0-alpha0159",
"NuGetVersion":"1.2.0-alpha0159",
"NuGetPreReleaseTagV2":"alpha0159",
"NuGetPreReleaseTag":"alpha0159",
"VersionSourceSha":"27566ce2e58925f60904bef84c6778f1fedcdd7f",
"CommitsSinceVersionSource":159,
"CommitsSinceVersionSourcePadded":"0159",
"CommitDate":"2020-08-27"
}This is my GitVersion.yml mode: ContinuousDeployment
next-version: 1.0.0
branches: {}
ignore:
sha: []
merge-message-formats: {}
And in my pipeline I have this steps:
- task: UseGitVersion@5
displayName: gitversion
inputs:
versionSpec: '5.x'
updateAssemblyInfo: false
useConfigFile: true
configFilePath: 'GitVersion.yml' |
|
I'm facing this issue too and I might have found an identifier to could lead to the root cause. In the reproduction of @garoyeri on April 6th, see this line I'm having the same line in my build log. Now look at this: And at this: So I conclude that GitVersion (in buildserver mode) creates a local branch from the tag, and makes that the current checked-out branch. Git itself warns about this branch which uses the same name as the tag: In this scenario, the branch points to the same commit (7ef) as the branch where is has been taken from. So questions I have:
@asbjornu: can you share your comments? Any pointers to the code where to look at? Or suggestions for the test fixture? |
|
@gerwinjansen, to answer your questions:
|
|
I think I have found the root cause. Here are my smallest steps to reproduce (powershell script): Because the branch 'tags/v1.0.1' or headless checkout do not have branch configuration in GitVersion.yml, it will try to inherit the configuration from a parent branch. But the log output shows: Now, GitVersion tries to find the first branch in the set of {develop, master}: Repository branches are sorted and the 'd' comes before the 'm' so develop configuration is selected. And the default increment for develop is Minor. There are 2 tags in the history, where 1.0.1 is pointing to the same commit as HEAD and the older 1.0 to a previous commit. This means that 1.0 is marked for increment, effectively a Minor increment based on the develop configuration, so it becomes a set of {1.1, 1.0.1}. And version 1.1 is selected. As far as I can see, GitVersion should first try to find the max from the tag(s) that are directly pointing to the same commit as HEAD. If there are none, then find the max of the remaining tags. |
100% agreed. Thank you so much for the investigation and to have found a possible solution to this bug! Would you be up for providing a pull request with the required code adjustments and a test that reproduces the problem? We already have some remote repository tests that both look relevant and should provide useful to reproduce this specific problem so we know that when it's fixed, it will be fixed for good: 🙏 |
|
I was able to rule the remote repository out. Here are optimized steps to reproduce: I was able to create a failing test for this scenario, see PR. If #2411 is applied, here are alternative steps to reproduce (without creating the ambiguous branch 'tags/v1.0.1', but working on a detached head) I'm not able to capture this scenario in a failing TestFixture. Maybe a problem with the GitTools.Testing when checking out a tag? I didn't investigate in detail. |
|
PR #2413 has only a failing test so far. My solution of preferring tags-on-the-current-commit has at least a conflict with I'm looking for guidance / feedback. Do we need to introduce the notion of Precedence in the code? For example, give every VersionStrategy an ordinal (10, 20, 30, ..), which it passes on to the BaseVersion when it creates one. Then TaggedCommitVersionStrategy can give tags-on-current-commit a lower ordinal (e.g. 30) than tag-from-history (e.g. 35). Other idea's welcome. And if someone wants to take the branch to fix the code and complete the PR: feel free. |
|
I think the idea of precedence by ordinal is great, @gerwinjansen. The seemingly random order strategies are applied now is at least not great. It will be interesting to see how many tests introducing this ordinal is going to break. 🤞 |
|
I have found another solution which is less invasive. |
|
🎉 This issue has been resolved in version 5.5.1 🎉 Your GitReleaseManager bot 📦🚀 |
|
I think this broken again in version I tagged my Here's the output from my GitHub workflow (run on my And here's my |
|
I also think this is still an issue: #3653 |
I am running GitVersion 5.1.3 on Windows Server 2019 connecting to BitBucket Cloud, and using TeamCity and its GitVersion metarunner to generate version numbers.
With a particular GitFlow repo that I have, I am building on
support/12.4and everything is great, GitVersion calculates the version number as e.g. 12.4.11-beta0003. However, when I tag that commit which I have just built as e.g. 12.4.12, then GitVersion completely ignores that tag and grabs the version number fromdevelop, giving me a tag something like 13.4.0-tags-12-4-11.1+8.It only does this on the build agent; when I run GitVersion on my desktop then it calculates the version correctly.
The text was updated successfully, but these errors were encountered: