Is it possible to have the result of git rev-list --count in a variable?

[chrbkr]

In our project, we switched from SVN to git. The versioning scheme was <major>.<minor>.<patch>.<revision>.

For continuity, I wanted to keep this scheme, by getting the equivalent of the SVN revision via git rev-list --count HEAD.

Is there a variable in GitVersion I can use for this? Or can this command be invoked in some other way when using GitVersionTask?

[JakeGinnivan]

This particular variable is not, we have a similar variable which is BuildMetaData, but this counts the commits since the version changed.

[chrbkr]

I see, thank you. Is there a way to call an external command in GitVersionTask or is the only possibility using GitVersion in a BeforeBuild task?

[jbaehr]

Please note that putting something like a svn revision or git rev-list --count HEAD in a version is not save in the long run. On Windows each of the four parts of a version can only hold 16 bits; see https://blogs.msdn.microsoft.com/msbuild/2007/01/03/why-are-build-numbers-limited-to-65535/
So after 65535 commits you get into trouble. And people already got into such trouble, just search on stack-overflow...

As I was looking for a solution for strictly monotonic increasing version numbers (to satisfy Windows Installer's requirements for "Major Upgrades") in the AssemblyFileVersionAttribute I was also tempted to simply use the total number of commits as the fourth digit. And because our repo had already more then 140k commits at that time I did some research. Indeed, it was a good idea to go another route...
(Our current approach is to use the build number from the CI-server; that can easily be reset when opening a release branch)

[asbjornu]

I think #1385 might provide a solution to this by allowing the result of git rev-list --count HEAD to be exposed as an environment variable and then that variable being used by GitVersion. Would that help, @chrbkr?

[chrbkr]

Sorry for the late response. Yes, this does definitely help. In order to mitigate the 16 bit limitation pointed out by @jbaehr, it might be useful to use git rev-list HEAD --count --first-parent (on master) instead, so only releases are counted (assuming a git-flow approach).
So, the approach would be to set an environment variable in MsBuild and use that in GitVersionTask?

[jbaehr]

@chrbkr just be careful with GitVersion's cache. We run GitVersion.exe with the /nocache-flag prior to the build, setup a "weighted prerelease number" env-var by applying a prerelease-label based offset to the commits-since-version-source and use that for the fourth digit (#1433 is an attempt to automate this further). The first call of the GitVersionTask creates the cache with the env-var already in place. This cache is then used by all subsequent GitVerionTask invocations.
(just using build number from the CI-server does not play well with Jenkins' multi-branch
pipelines; thus we don't use what I described in an earlier comment anymore)

When you just set the env-var and only relies on GitVersionTask, you may have to find a way to tell the Task to ignore the cache (which will have a performance impact on large repos when building many projects). Or ensure the env-var is there in all cases.

Finally just use your env-var in GitVersion's format strings, see the "*-format" keys in https://gitversion.readthedocs.io/en/stable/configuration/

[stale]

This issue has been automatically marked as stale because it has not had recent activity. After 30 days from now, it will be closed if no further activity occurs. Thank you for your contributions.

[vincentcastagna]

So I got kind of the same question. We are migrating an old project to use gitversion. However, this project was relying on git rev-list HEAD --count. Now I update the pipelines to rely on the PreReleaseNumber, however its far off the git count. Isn't there a way to PreReleaseNumber aligned ? Because at a point this prevent us from pushing application to store as the build number must be always higher than previous pushed build.

[asbjornu]

Can't you use the build counter as a parameter in the version number then, @vincentcastagna?

[vincentcastagna]

Hey @asbjornu can you elaborate please ? Where to get that build counter (you mean the git count ) ?

[asbjornu]

You get that from the build system. TeamCity exposes a variable called build.counter, for instance.

[vincentcastagna]

@asbjornu any official doc about this variable ? Cause can't find.

[asbjornu]

You will have to check with your build server. Which one do you use, @vincentcastagna?