Remove GitVersion_PreReleaseTagWithDash from GitVersion_SemVer Value

[BenB196]

Hi All,

I have a question that I was wondering if anyone could help me with.

I'm attempting to cut a production/stable release with GitVersion, but the release always seems to include the GitVersion_PreReleaseTagWithDash as part of GitVersion_SemVer, would anyone know how to get GitVersion_SemVer to generate without GitVersion_PreReleaseTagWithDash?

My configuration:

mode: ContinuousDelivery
version-in-branch-pattern: (?<version>[vV]?\d+(\.\d+)?(\.\d+)?).*
major-version-bump-message: "(\+semver:\s?(breaking|major))"
minor-version-bump-message: "(\+semver:\s?(feature|minor))"
patch-version-bump-message: "(\+semver:\s?(fix|patch))"
no-bump-message: '\+semver:\s?(none|skip)'
commit-message-incrementing: MergeMessageOnly
branches:
  main:
    regex: ^master$|^main$|^dev(elop)?(ment)?$
    source-branches: [ 'release' ]
    label: alpha
    is-mainline: true
    tracks-release-branches: true
    pre-release-weight: 0
  release:
    regex: ^releases?[/-]
    label: beta
    increment: None
    prevent-increment-of-merged-branch-version: true
    track-merge-target: false
    source-branches: [ 'main', 'release' ]
    tracks-release-branches: false
    is-release-branch: true
    is-mainline: false
    pre-release-weight: 30000
  testing:
    regex: ^testing$
    source-branches: [ 'release' ]
    label: beta
    is-mainline: true
    tracks-release-branches: true
    track-merge-target: true
    pre-release-weight: 30000
  staging:
    regex: ^staging$
    source-branches: [ 'release' ]
    label: rc
    is-mainline: true
    tracks-release-branches: true
    track-merge-target: true
    pre-release-weight: 30000
  production:
    regex: ^production$
    source-branches: [ 'release' ]
    label: ''
    is-mainline: true
    tracks-release-branches: true
    track-merge-target: true
    pre-release-weight: 30000

Basic Flow:

1. Developers commit directly to main/develop.
   • main is deployed to a "Development" environment for active Developer testing.
   • Example: 4.0.1-alpha.1
2. When it is time to create a release, a release branch (release/x.y.z) is cut from main.
3. Once the release is ready, the release branch is merged into the testing branch.
   • testing is deploying to a "Testing" environment for active QA.
   • Example: 4.0.1-beta.1
4. Once the release branch has passed QA, then the release branch is merged into the staging branch.
   • staging is deployed to a "Staging" environment for active UAT.
   • Example: 4.0.1-rc.1
5. Once the release branch has passed UAT, then the release branch is merged into the production branch.
   • production is deployed to the "Production" environment for general consumption.
   • This where I'm hitting the issue:
     • I want: 4.0.1
     • I get: 4.0.1-1
     • This is what I see looking at the GitVersion output:

GitVersion_Major=4
GitVersion_Minor=0
GitVersion_Patch=1
GitVersion_BuildMetaData=0
GitVersion_FullBuildMetaData=0.Branch.production.Sha.4d10bebc3fc11f80d9226f033262c339e3d4e1c6
GitVersion_BranchName=production
GitVersion_EscapedBranchName=production
GitVersion_Sha=4d10bebc3fc11f80d9226f033262c339e3d4e1c6
GitVersion_ShortSha=4d10beb
GitVersion_MajorMinorPatch=4.0.1
GitVersion_SemVer=4.0.1-1
GitVersion_FullSemVer=4.0.1-1+0
GitVersion_AssemblySemVer=4.0.1.0
GitVersion_AssemblySemFileVer=4.0.1.0
GitVersion_PreReleaseTag=1
GitVersion_PreReleaseTagWithDash=-1
GitVersion_PreReleaseLabel=
GitVersion_PreReleaseLabelWithDash=
GitVersion_PreReleaseNumber=1
GitVersion_WeightedPreReleaseNumber=[300](https://<snipped>/<snipped>/ci-cd-templates/release-coordinator/-/jobs/189594#L300)01
GitVersion_InformationalVersion=4.0.1-1+0.Branch.production.Sha.4d10bebc3fc11f80d9226f033262c339e3d4e1c6
GitVersion_CommitDate=2023-10-02
GitVersion_VersionSourceSha=4d10bebc3fc11f80d9226f033262c339e3d4e1c6
GitVersion_CommitsSinceVersionSource=0
GitVersion_UncommittedChanges=2

Would anyone know how to get 4.0.1 rather than 4.0.1-1 for the production version in the GitVersion_SemVer value?

Edit: Forgot to mention that I'm using GitVersion 6.0.0-beta.3 in case that helps at all.

[HHobeck]

You mean this?

[Test]
public void __Just_A_Test__()
{
    var configuration = GitHubFlowConfigurationBuilder.New.WithLabel(null)
        .WithBranch("main", _ => _.WithVersioningMode(VersioningMode.ContinuousDeployment).WithLabel(null))
        .Build();
    using var fixture = new EmptyRepositoryFixture("main");

    fixture.MakeATaggedCommit("1.0.0");

    fixture.MakeACommit();

    // ✅ succeeds as expected
    fixture.AssertFullSemver("1.0.1", configuration);
}

Please see the following integration test:

GitVersion/src/GitVersion.Core.Tests/IntegrationTests/ComparingTheBehaviorOfDifferentVersioningModes.cs

Line 12 in dcd8827

internal class ComparingTheBehaviorOfDifferentVersioningModes

[BenB196]

Hi @HHobeck thanks for pointing to this test.

Looking at it I can see 4 things:

1. Use GitHubFlow/v1
2. Use ContinuousDeployment
3. Use Label null
4. Use main branch

Question, I tested my config with the following changes:

mode: ContinuousDelivery
version-in-branch-pattern: (?<version>[vV]?\d+(\.\d+)?(\.\d+)?).*
major-version-bump-message: "(\+semver:\s?(breaking|major))"
minor-version-bump-message: "(\+semver:\s?(feature|minor))"
patch-version-bump-message: "(\+semver:\s?(fix|patch))"
no-bump-message: '\+semver:\s?(none|skip)'
commit-message-incrementing: MergeMessageOnly
+ workflow: 'GitHubFlow/v1'
branches:
  main:
    regex: ^master$|^main$|^dev(elop)?(ment)?$
    source-branches: [ 'release' ]
    label: alpha
    is-mainline: true
    tracks-release-branches: true
    pre-release-weight: 0
  release:
    regex: ^releases?[/-]
    label: beta
    increment: None
    prevent-increment-of-merged-branch-version: true
    track-merge-target: false
    source-branches: [ 'main', 'release' ]
    tracks-release-branches: false
    is-release-branch: true
    is-mainline: false
    pre-release-weight: 30000
  testing:
    regex: ^testing$
    source-branches: [ 'release' ]
    label: beta
    is-mainline: true
    tracks-release-branches: true
    track-merge-target: true
    pre-release-weight: 30000
  staging:
    regex: ^staging$
    source-branches: [ 'release' ]
    label: rc
    is-mainline: true
    tracks-release-branches: true
    track-merge-target: true
    pre-release-weight: 30000
  production:
+   mode: ContinuousDeployment
    regex: ^production$
    source-branches: [ 'release' ]
    label: ''
    is-mainline: true
    tracks-release-branches: true
    track-merge-target: true
    pre-release-weight: 30000

But when merge release/x.y.z to production I now get

GitVersion_MajorMinorPatch=4.0.6
GitVersion_SemVer=4.0.6-17
GitVersion_FullSemVer=4.0.6-17

Is there a way to change the config to use production branch instead of main here, or does it need to be main?

[HHobeck]

I'm actually not sure if you are extending/inheriting from the GitHubFlow/v1 workflow or specifying a complete new workflow. If the second case is true you should define the workflow property to an empty string workflow: '' to have no base configuration.

Anyway in your scenario you could of course define a new branch configuration with the name production. Because the label is set to an empty string you get a pre-release with an empty label. If you set it to null you will get no pre-release versions.

Edit: Empty and null strings have a different meaning here.

Edit: If you want to reuse the configuration of main you can do this by just changing the regex property:

workflow: 'GitHubFlow/v1'
label:
branches:
  main:
    label:
    regex: '^production$'

[BenB196]

Hi @HHobeck

I'm actually not sure if you are extending/inheriting from the GitHubFlow/v1 workflow or specifying a complete new workflow. If the second case is true you should define the workflow property to an empty string workflow: '' to have no base configuration.

It's a weird flow, but it is based on GitHubFlow, essentially, it is GitHubFlow, but rather than merging directly back into main, releases are "prompted" (merged) into testing/staging/production which all function as their own mainlines.

Edit: Empty and null strings have a different meaning here.

Interesting, today I learned.

I attempted to use something like:

branches:
  main:
    label:
    regex: '^production$'

But this caused some versioning issues with the old main renamed, where it wasn't incrementing properly.

I tested a few more things, but wasn't able to get any to work. I was hoping maybe you could help answer a question, I was looking through the docs and found: https://github.com/GitTools/GitVersion/blob/main/docs/input/docs/reference/version-increments.md#incrementing-per-commit specifically:

When using the continuous deployment mode (which will increment the SemVer every commit) all builds must have a pre-release tag, except for builds that are explicitly tagged as stable.

Would you know what it means by:

all builds must have a pre-release tag, except for builds that are explicitly tagged as stable.

How does a build get tagged as stable via GitVersion? This is something I can't find within the docs.

[HHobeck]

Please ensure that the label on the root level is set to null as well otherwise it will be used as fallback:

workflow: 'GitHubFlow/v1'
label:
branches:
  main:
    label:
    regex: '^production$'

If you tag a version without a pre-release label e.g. 1.0.0 then the source code stage will be treated as Release to Production (RTM) (stable version). If you tag it with e.g. 1.0.0-rc.1 it will be treated as a Release Candidate (RC) (preview version).