How does VersionInBranchBaseVersionStrategy handle version extraction ?

[nzeugaa]

I have a case where i need the release branch to have a prefix like release/uat/v1.2.1.

Gitversion is not able to extract the correct verion for the release in this case. I'm expecting 1.2.1 to be extracted. Am I missing something here ? Do I need to override default config to have the behavior I'm expecting ?

[asbjornu]

As you can see from the documentation, the default pattern is:

version-in-branch-pattern: (?<version>[vV]?\d+(\.\d+)?(\.\d+)?).*

This pattern should indeed capture v1.2.1 from release/uat/v1.2.1. Is the branch correctly identified as a release branch? Do you have logs from the build you can share?

[nzeugaa]

My understanding was that having a release/** branch should be automatically recognised as a release branch... You can see from the logs that I've created release/uat/v1.0.14, however GitVersion is determining 1.1.0-beta.1 as Semver

Run gittools/actions/gitversion/[email protected]
Running on: 'GitHub Actions'
Disable Telemetry
Executing GitVersion
Command: git -C /home/runner/work/fsmart/fsmart rev-parse --is-shallow-repository
Command: /opt/hostedtoolcache/GitVersion.Tool/6.0.2/dotnet-gitversion /home/runner/work/fsmart/fsmart /output json /output buildserver
GitVersion executed successfully
GitVersion output:
-------------------
INFO [24-09-02 21:05:02:75] Working directory: /home/runner/work/fsmart/fsmart
INFO [24-09-02 21:05:02:76] Project root is: /home/runner/work/fsmart/fsmart/
INFO [24-09-02 21:05:02:76] DotGit directory is: /home/runner/work/fsmart/fsmart/.git
INFO [24-09-02 21:05:02:76] Branch from build environment: refs/heads/release/uat/v1.0.14
INFO [24-09-02 21:05:02:76] -< Begin: Normalizing git directory for branch 'refs/heads/release/uat/v1.0.14' >-
  INFO [24-09-02 21:05:02:79] One remote found (origin -> '****').
  INFO [24-09-02 21:05:02:79] Skipping fetching, if GitVersion does not calculate your version as expected you might need to allow fetching or use dynamic repositories
  INFO [24-09-02 21:05:02:81] Updating local branch release/uat/v1.0.14 to point at ec01f8c
  
  
  INFO [24-09-02 21:05:02:87] HEAD points at branch 'refs/heads/release/uat/v1.0.14'.
INFO [24-09-02 21:05:02:87] -< End: Normalizing git directory for branch 'refs/heads/release/uat/v1.0.14' (Took: 102.06ms) >-
INFO [24-09-02 21:05:02:88] -< Begin: Loading version variables from disk cache file /home/runner/work/fsmart/fsmart/.git/gitversion_cache/271028B317418D569116E1445647FBE34794626E >-
INFO [24-09-02 21:05:02:91] -< End: Loading version variables from disk cache file /home/runner/work/fsmart/fsmart/.git/gitversion_cache/271028B317418D569116E1445647FBE34794626E (Took: 25.87ms) >-
Executing GenerateSetVersionMessage for 'GitHubActions'.

Executing GenerateBuildLogOutput for 'GitHubActions'.
Writing version variables to $GITHUB_ENV file for 'GitHubActions'.
{
  "AssemblySemFileVer": "1.1.0.0",
  "AssemblySemVer": "1.1.0.0",
  "BranchName": "release/uat/v1.0.14",
  "BuildMetaData": 47,
  "CommitDate": "2024-09-02",
  "CommitsSinceVersionSource": 47,
  "EscapedBranchName": "release-uat-v1-0-14",
  "FullBuildMetaData": "47.Branch.release-uat-v1.0.14.Sha.ec01f8c6ceadc69d221d3d8eebfb8a69aefebed0",
  "FullSemVer": "1.1.0-beta.1+47",
  "InformationalVersion": "1.1.0-beta.1+47.Branch.release-uat-v1.0.14.Sha.ec01f8c6ceadc69d221d3d8eebfb8a69aefebed0",
  "Major": 1,
  "MajorMinorPatch": "1.1.0",
  "Minor": 1,
  "Patch": 0,
  "PreReleaseLabel": "beta",
  "PreReleaseLabelWithDash": "-beta",
  "PreReleaseNumber": 1,
  "PreReleaseTag": "beta.1",
  "PreReleaseTagWithDash": "-beta.1",
  "SemVer": "1.1.0-beta.1",
  "Sha": "ec01f8c6ceadc69d221d3d8eebfb8a69aefebed0",
  "ShortSha": "ec01f8c",
  "UncommittedChanges": 0,
  "VersionSourceSha": "9f4daf1890ceff83f58ba05fed6ae6a9659ca9dd",
  "WeightedPreReleaseNumber": 30001
}

[HHobeck]

Git version determines the possible versions based on the defined version strategies and takes the highest version number available. In your example 1.0.14 is less than 1.1.0.

[HHobeck]

In the GitFlow workflow we have defined the hotfix branch and configured it with is-release-branch: true as well. Probably you need to use the hotfix branch instead of release branch. (see Link[1])

In the GitHubFlow workflow this is not necessary because the release branch is set to increment patch. (see Link[2])

Link[1]: GitFlow Examples
Link[2]: GitHubFlow Examples

[nzeugaa]

Then how Git Version determines 1.1.0 as highest version ? I have no reference to 1.1.0 ... my understanding is that 1.0.14 should have been the highest version number

[HHobeck]

In the GitHubFlow workflow this is not necessary because the release branch is set to increment patch. (see Link[2])

In the GitFlow workflow it is intentionally because the release branch is set to increment minor.

If you want to patch a version you need to:

• not use the release but the hotfix branch or
• change the increment on release branch or
• use the GitHubFlow workflow.

Link[1]: GitFlow Examples