gitversion reports different on windows than on mac. Why?

Question

It's so simple: I am trying to use gitversion to manage semver and I am getting completely different behavior on the same repo/branch/commit between windows and mac. I am hoping someone can explain because I can't manage a version bump without it.

mac:

cbongiorno at 5cg4461z2l in ~/dev/adaptors on master [$]
$  git log -1 --pretty=oneline
e7592b7703792069e4f1a69317ef50fa1deae2eb (HEAD -> master, origin/master) PE20-165 - fix the command, again!

cbongiorno at 5cg4461z2l in ~/dev/adaptors on master [$]
$ gitversion /version
5.1.3+Branch.master.Sha.bef8ebc0b62b3ddd0cdafe09b66d68bbfcaf90d5

cbongiorno at 5cg4461z2l in ~/dev/adaptors on master [$]
$ git rev-parse --abbrev-ref HEAD
master

cbongiorno at 5cg4461z2l in ~/dev/adaptors on master [$]
$ gitversion
{
  "Major":0,
  "Minor":2,
  "Patch":1,
  "PreReleaseTag":"",
  "PreReleaseTagWithDash":"",
  "PreReleaseLabel":"",
  "PreReleaseNumber":"",
  "WeightedPreReleaseNumber":"",
  "BuildMetaData":19,
  "BuildMetaDataPadded":"0019",
  "FullBuildMetaData":"19.Branch.master.Sha.e7592b7703792069e4f1a69317ef50fa1deae2eb",
  "MajorMinorPatch":"0.2.1",
  "SemVer":"0.2.1",
  "LegacySemVer":"0.2.1",
  "LegacySemVerPadded":"0.2.1",
  "AssemblySemVer":"0.2.1.0",
  "AssemblySemFileVer":"0.2.1.0",
  "FullSemVer":"0.2.1+19",
  "InformationalVersion":"0.2.1+19.Branch.master.Sha.e7592b7703792069e4f1a69317ef50fa1deae2eb",
  "BranchName":"master",
  "Sha":"e7592b7703792069e4f1a69317ef50fa1deae2eb",
  "ShortSha":"e7592b7",
  "NuGetVersionV2":"0.2.1",
  "NuGetVersion":"0.2.1",
  "NuGetPreReleaseTagV2":"",
  "NuGetPreReleaseTag":"",
  "VersionSourceSha":"800649c8102414d2513a19253ff2a4caadafb2ab",
  "CommitsSinceVersionSource":19,
  "CommitsSinceVersionSourcePadded":"0019",
  "CommitDate":"2020-02-20"
}

Windows:

PS C:\Users\cbongiorno> cd E:\SysData\Jenkins\workspace\chb0_chb0mb_master
PS E:\SysData\Jenkins\workspace\chb0_chb0mb_master> git log -1 --pretty=oneline
e7592b7703792069e4f1a69317ef50fa1deae2eb (HEAD -> master, tag: 0.1.0, origin/master) PE20-165 - fix the command, again!
PS E:\SysData\Jenkins\workspace\chb0_chb0mb_master> gitversion /version
5.1.3+Branch.master.Sha.bef8ebc0b62b3ddd0cdafe09b66d68bbfcaf90d5
PS E:\SysData\Jenkins\workspace\chb0_chb0mb_master> gitversion
{
  "Major":0,
  "Minor":1,
  "Patch":0,
  "PreReleaseTag":"",
  "PreReleaseTagWithDash":"",
  "PreReleaseLabel":"",
  "PreReleaseNumber":"",
  "WeightedPreReleaseNumber":"",
  "BuildMetaData":"",
  "BuildMetaDataPadded":"",
  "FullBuildMetaData":"Branch.master.Sha.e7592b7703792069e4f1a69317ef50fa1deae2eb",
  "MajorMinorPatch":"0.1.0",
  "SemVer":"0.1.0",
  "LegacySemVer":"0.1.0",
  "LegacySemVerPadded":"0.1.0",
  "AssemblySemVer":"0.1.0.0",
  "AssemblySemFileVer":"0.1.0.0",
  "FullSemVer":"0.1.0",
  "InformationalVersion":"0.1.0+Branch.master.Sha.e7592b7703792069e4f1a69317ef50fa1deae2eb",
  "BranchName":"master",
  "Sha":"e7592b7703792069e4f1a69317ef50fa1deae2eb",
  "ShortSha":"e7592b7",
  "NuGetVersionV2":"0.1.0",
  "NuGetVersion":"0.1.0",
  "NuGetPreReleaseTagV2":"",
  "NuGetPreReleaseTag":"",
  "VersionSourceSha":"e7592b7703792069e4f1a69317ef50fa1deae2eb",
  "CommitsSinceVersionSource":92,
  "CommitsSinceVersionSourcePadded":"0092",
  "CommitDate":"2020-02-20"
}
PS E:\SysData\Jenkins\workspace\chb0_chb0mb_master> git rev-parse --abbrev-ref HEAD
master

The version numbers are totally different even though I am dealing with the same repo/commit. This HAS to be a bug.

Can anyone explain this?

Am I right in saying that the Mac machine in question is your own machine, and the Windows machine is a Jenkins build agent? If so, I am going to guess that the issue is to do with Jenkins doing a shallow clone, rather than cloning the entire repository (which happens by default on your own machine). In order to work correctly, GitVersion needs the entire history of the repository to be present on the machine the version number is being asserted on. — Gary Ewan Park, Feb 20 '20 at 16:18
If you are really interested in adhering to [SemVer](https://semver.org), don't use GitVersion. The authors of that tool do not seem to understand SemVer. — jwdonahue, Feb 24 '20 at 00:16
Can you explain that @jwdonahue ? Can you recommend another tool? — Christian Bongiorno, Feb 24 '20 at 05:09
It would be great if you could clarify that comment, @jwdonahue. — Asbjørn Ulsberg, Feb 25 '20 at 23:22
Oh, sorry, I meant to get back to this yesterday. Like most common tools in use today, GitVersion is not a pure SemVer tool. It's more about workflows and how they impact when to bump a version string. The tool defaults to a behavior that violates a strict reading of the [SemVer](https://semver.org) spec. It can produce the same version string from multiple builds. There should never be more than one version string per output hash. Few, if any, build system can produce the same output twice in a row, even against the same code. That's ignoring OS, tooling and library updates. — jwdonahue, Feb 25 '20 at 23:28
So you have to be quite careful about your workflow selections and tooling configurations, if you use GitVersion, and you intend to be SemVer compliant. — jwdonahue, Feb 25 '20 at 23:30
Agreed. GitVersion is unable to guarantee a unique version number across all commits, refs and possible configurations in a single repository. It would have to provide some persistent storage for previously generated version numbers to be able to guarantee that. However, if you follow one of the supported workflows by the book, this shouldn't be an issue in practice. — Asbjørn Ulsberg, Feb 26 '20 at 10:32
that's a lot of caveats @AsbjørnUlsberg - I am going to encourage githubflow to the team in question — Christian Bongiorno, Feb 26 '20 at 11:30
Ensuring unique version numbers is simply out of scope for a tool such as GitVersion. To ensure that, you need to use a release manager such as [Octopus Deploy](https://octopus.com/). GitHubFlow is a supported workflow so it should work just fine. — Asbjørn Ulsberg, Feb 27 '20 at 08:50

gitversion reports different on windows than on mac. Why?

0 Answers0