Skip to content
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] When PreleaseLabel is empty, the PreleaseTag is not correctly generated #2347

Closed
dramdrung opened this issue Jul 2, 2020 · 3 comments · Fixed by #3447
Closed

[Bug] When PreleaseLabel is empty, the PreleaseTag is not correctly generated #2347

dramdrung opened this issue Jul 2, 2020 · 3 comments · Fixed by #3447
Labels
Milestone

Comments

@dramdrung
Copy link

Describe the bug

In ContinousDeployment or Mainline mode I would like to use the CommitsSinceVersionSource as PreleaseTag without any additional PrereleaseLabel before it.
In order to achieve that I tried to set the PrereleaseTag to empty but in such case the CommitsSinceVersionSource is not properly processed to the Prerelease properties.

After looking through the code it seems that such behavior might be intended for Mainline mode as there are a lot of tests where by default for FullSemVer is expected format MajorMinorPatch instead of MajorMinorPatch-PrereleaseTag (PrereleaseLabel.PrereleaseNumber).


Is this expected behavior? When there is no PrereleaseLabel, there won't be PrereleaseTag generated from just Number?

Shouldn't CommitsSinceVersionSource taken as PrereleaseNumber generate PrereleaseTag at least for ContinuousDeployment mode, even if PrereleaseLabel is empty?
As it is mentioned in source code comment (VariableProvider.cs, Line 29):

// Continuous Deployment always requires a pre-release tag unless the commit is tagged


Example of the generated properties for ContinuousDeployment:
image

There is only PrereleaseTag set to the value of CommitsSinceVersionSource, without any formatting.
Even the PrereleaseNumber is not properly returned.
The FullSemVer include only MajorMinorPatch.

Expected Behavior

With GitVersion.yml:

assembly-versioning-scheme: MajorMinorPatch
continuous-delivery-fallback-tag: ''
branches:
  master:
    mode: ContinuousDeployment

The Prelease properties generated should look like this:

"PreReleaseTag": "3",
"PreReleaseTagWithDash":"-3",
"PreReleaseLabel":"",
"PreReleaseNumber":"3",
"FullSemVer":"5.3.8-3",

In relation to Properties shown below:
image

Actual Behavior

With GitVersion.yml:

assembly-versioning-scheme: MajorMinorPatch
continuous-delivery-fallback-tag: ''
branches:
  master:
    mode: ContinuousDeployment

The output generated looks like this:
image

Possible reason

The CommitsSinceVersionSource are set as Number for PrereleaseTag properly but in turn the PromotedFromCommits flag is set.
Then the Properties are not properly handled by SemanticVersionFormatValues due to HasTag method in SemanticVersionPreReleaseTag class.
The HasTag returns false due to PromotedFromCommits flag being true and Name being null/empty, in result SemanticVersionFormatValues doesn't return proper values.

Steps to Reproduce

Use GitVersion.yml config file:

assembly-versioning-scheme: MajorMinorPatch
continuous-delivery-fallback-tag: ''
branches:
  master:
    mode: ContinuousDeployment

Make several commits, and then check the generated output of GitVersion.
The Prerelease properties should not be generated properly.
The FullSemVer doesn't include the PrereleaseTag as well.

Context

In ContinousDeployment or Mainline mode I would like to use the CommitsSinceVersionSource as PreleaseTag without any additional PrereleaseLabel before it. The number of commits is enough without any additional string.

Your Environment

  • Version Used: 5.3.7+Branch.master.Sha.b22e8726683a0997484b53c5efd54394e93b5306
  • Operating System and version (Windows 10, Ubuntu 18.04): Windows 10
@asbjornu
Copy link
Member

I think your request makes sense, @dramdrung. Could you please submit a PR with some tests and perhaps even a fix to just see whether this would break (many) other tests by fixing?

@HHobeck
Copy link
Contributor

HHobeck commented Mar 22, 2023

Maybe we need to make this behavior configurable!? @asbjornu Do you have any suggesions?

@arturcic
Copy link
Member

arturcic commented Apr 6, 2023

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

Your GitReleaseManager bot 📦🚀

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants