-
Notifications
You must be signed in to change notification settings - Fork 653
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[BUG]: GitVersion (in Azure Devops) calculating wrong version when building a tag #4015
Comments
I believe this is fixed in v6. Can you upgrade and try it out? |
It doesn't seem fixed, as GitVersion still generates a prerelease version. I had to change
and I don't think it should add any +semver here because commit dc43f3b is exactly the commit where tag v_0.1.2 points to. This is the full output from a v6 run:
|
@HHobeck, is it expected behavior that tagged commits aren't picked up with the |
If it's any help, I'm seeing the same issue when using GitVersion 5.10.3 on GitHub Actions. If I create a release in GitHub and tag it as e.g. |
To answer your question: Yes of course the TrunkBased workflow (which uses the Mainline version stratgey) considers tags. Anyway I think it has nothing to do with the used strategy. If you see the log output then you see the following:
That means the current branch is of name tags/v_0.1.2. Because we have no branch configuration with name tags the algorithm uses the unknown branch configuration. unknown:
increment: Patch
regex: (?<BranchName>.+)
prevent-increment:
when-current-commit-tagged: false
source-branches:
- main
pre-release-weight: 30000 |
@HHobeck as I suspected. So it is the repository normalization that is causing this problem, which I thought was fixed. Oh well. |
The normalization process is something I have not touched. I have a common understanding what this module does but don't know the overall design. I think the behavior having a branch with name e.g. tags/1.0.0 is also something I have seen with azure devops as well. Maybe it is by design and we need to change the configuration and add a tags branch configuration? Or let me ask the question different: Which branch would you use in the normalization process when starting the artefact creation by selecting just a tag? Maybe this discussion goes in the same direction: #3907 |
Note that this is only an issue in Mainline mode. If I change my configuration to
|
@arnoschuring-miele: In the log output you see the following line:
That means independent of wish mode you are using there is no configuration for tags in the configuration present. Maybe I need to say that I have no idea why it is not working with the Mainline mode. Anyway I want to point out that the |
As I wrote in #4183 (reply in thread):
|
I ran into the same issue using GitVersion 6.0.2 and Azure DevOps. Unfortunately the tagged branches produced semantic versions as follows: {
"AssemblySemFileVer": "25.4.2.0",
"AssemblySemVer": "25.4.2.0",
"BranchName": "tags/25.4.0",
"BuildMetaData": 0,
"CommitDate": "2024-09-08",
...
"FullSemVer": "25.4.2-tags-25-4-0.1+0"
} For now, I've just managed to workaround adding a tag branch as follows: tags:
mode: ContinuousDeployment
regex: tags?[/-]\d+\.\d+\.\d+
source-branches: ['main','release','hotfix']
increment: none Using this change, tags are receiving a semantic version as desired: {
"AssemblySemFileVer": "25.7.0.0",
"AssemblySemVer": "25.7.0.0",
"BranchName": "tags/25.7.0",
"BuildMetaData": null,
"CommitDate": "2024-09-08",
...
"FullSemVer": "25.7.0"
} Nevertheless, this is not optimal as it doesn't take tagPrefixes etc. into account. |
Prerequisites
GitVersion package
AzureDevops task
GitVersion version
5.12.0
Operating system
Linux
What are you seeing?
When building on a tag in Azure Devops, GitVersion is generating a new pre-release version rather than using the already-placed tag. This seems entirely similar to #2074 and #2456.
The current config is quite minimal:
I cannot run this locally to get more info, because a) when I do a git checkout of the tag locally, it generates the correct version number, and b) it seems to completely ignore any -verbosity argument specified.
I suspect this line (from the log) is the problem:
And that may be because we merged the same branch twice:
What is expected?
GitVersion should generate a version number that matches exactly the already-placed tag v_0.1.2 (as it does locally)
Steps to Reproduce
I have not been able to reproduce this locally, even with the exact git checkout procedure that ADO is using:
RepositoryFixture Test
No response
Output log or link to your CI build (if appropriate).
The text was updated successfully, but these errors were encountered: