Where communities thrive

  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
Repo info
  • Jun 15 2020 13:06
    arturcic unlabeled #2095
  • Jun 15 2020 13:05
    arturcic opened #2328
  • Jun 15 2020 08:09
    github-actions[bot] commented #2122
  • Jun 15 2020 08:09
    github-actions[bot] commented #2300
  • Jun 15 2020 08:09
    github-actions[bot] commented #2306
  • Jun 15 2020 08:09
    github-actions[bot] commented #2310
  • Jun 15 2020 08:09
    github-actions[bot] commented #2311
  • Jun 15 2020 08:09
    github-actions[bot] commented #2320
  • Jun 15 2020 08:09
    github-actions[bot] commented #2327
  • Jun 15 2020 07:49
    arturcic milestoned #2095
  • Jun 15 2020 07:49
    arturcic demilestoned #2095
  • Jun 15 2020 07:46

    arturcic on 5.3.6


  • Jun 15 2020 07:27
    arturcic demilestoned #2241
  • Jun 15 2020 07:27
    arturcic unassigned #2241
  • Jun 15 2020 07:27
    arturcic demilestoned #2074
  • Jun 15 2020 07:26
    arturcic milestoned #2327
  • Jun 15 2020 07:25
    arturcic demilestoned #2318
  • Jun 15 2020 07:25
    arturcic milestoned #2122
  • Jun 15 2020 07:25
    arturcic labeled #2122
  • Jun 15 2020 07:23
    arturcic demilestoned #2313
Kim J. Nordmo
sounds like it suddenly decided to honor the git depth flag then, honestly I am stumped and got no other suggestions at the moment.
Seems you would need to wait until you hear back from @arturcic or @asbjornu instead.....
I know gitversion works on travis-ci.org, but I have never tried it on travis-ci.com (but in my mind, there shouldn't really be any difference).
Nicolai Brogaard
I don't think there's a difference between travis-ci.com and travis-ci.org anymore - but it used to be the difference between public and private repos
Alexander Trauzzi

Hey again everyone, more detail on my problem from a few days ago:

mode: Mainline
increment: Patch
    mode: ContinuousDeployment

When I'm running the above configuration, when I go to generate a version off of master following a merge of develop into it, I get the following error: Mainline development mode doesn't yet support pre-release tags on master

What's weird is that I've never tagged master with any pre-release tags. Only my develop commits have been the target of pre-release tags... I basically want pre-release behaviour on my develop branch, but any time I merge to master, I want it to cause a minor version increment.

Werner Kapferer
Hey everybody :)
I seem to have problem running gitversion.exe with mono on Debian (Sid).
Am I missing something or is it currently not working for anybody else?
Mono JIT compiler version
Kim J. Nordmo
@woernsn You can't run GitVersion.exe with mono.
You will either need to downgrade the version to 5.0.1, or use the .NET Core tool of gitversion instead (I recommend this aproach).
Werner Kapferer
Thanks @AdmiringWorm !
Maybe you should state that in https://gitversion.net/docs/ too.
Might help other (also) lost persons :D.
I will take a look at the .NET Core tool.
Tim Long

Is anyone using GitVersionTask in a GitHub workflow action? I've just tried to set it up and got a rather confusing error message:

GitVersionTask.targets(46,9): error : GitVersionException: Cannot find commit 2108544aed45614f96f35440d4fadfa70773b8e0. Please ensure that the repository is an unshallow clone with git fetch --unshallow
eek! What do I do?

5 replies
Daniel Valadas
I am confused, I have many branches and everything works as expected without a config, now say I create a release/4.0.0 branch I do get v4.0.0, then when I merge that to master it gets either v3.2.1 or v4.0.1 no matter what kind of config I try. According to my understanding I was expected that merge to produce the verison specified in the release branch when merging it to master ?
2 replies
Josef Trejbal
Hello :)
I would like to ask how to properly increment version in release branch? Lets say I have version 0.1.0-beta1 , then i found issue, fixed it and i would like to increment to beta-2.. How this should be done? Version is not incrementing per commit (I suppose its because default mode for release branch is ContinuousDelivery).. So correct way is use tag? Thank you
Gary Ewan Park
@PepekT You would create a tag 0.1.0-beta1 and then it should increment
Josef Trejbal
@gep13 So release branch should increment per tag right?
Gary Ewan Park
That is how I have always done it.
Trent Scholl

Hoping somebody can point out what I'm doing wrong here...
I'm using ContinuousDeployment mode for this flow
Commit to master and run gitversion, it outputs 1.1.0-ci.0
Create a release branch (release/v1.1) from master and run gitversion, it outputs v1.1.0-beta.0
Tag the HEAD commit of release/v1.1 and run gitversion on the tag, ERROR

It looks like the branch being examined is a detached Head pointing to commit '88e98c4'. Without a proper branch name GitVersion cannot determine the build version.

According to the documentation gitversion should just use the tag name and not try to figure out a branch?
Kim J. Nordmo
@TrentScholl gitversion need the full git history, which is what I assume is causing the problem that you are seeing.
Are you running on a CI server? If so which one?
Trent Scholl
Running locally
Kim J. Nordmo
I see, in that case it sounds more like a bug to me. Not sure how you would be able to work around it though, unfortunately.
I thought the metadata of the version number was able to increment a number each time a build ran but this doesn't seem to be the case. Did it used to be and changed? Or am I doing something wrong? Or is this just something that never occurred?
To have GitVersion working on Azure DevOps am I supposed to install the NuGet Package? The documentation is confusing, it says "either using the Command Line build step or install an extension / custom build step" but the 1st step on "Executing GitVersion" is to install the NuGet package.
Patrick B
I'm a bit interested in that well. I just started reading up on gitversion and use ADO

But, I joined gitter to ask specifically about monorepos.

I have a large monorepo that I would like to try and tackle if possible. I see some mention of using tag prefixes.

Lets say I have the following

\SuperLibraryThing (NuGet package)
\AnotherLibraryThing (NuGet package)
\SuperApp (ASP.NET Core web app)

I assume I would potentially have a different GitVersion.yml in each of those folders, and I would perhaps set tag-prefix: superlibrarything for the first GitConfig.yml, tag-prefix: anotherlibrarything, for the second, etc

Gary Ewan Park
@PatrickBig GitVersion asserts a single set of Version Numbers for the entire repository. It doesn't have any concept of asserted different version numbers of different folders within the repository.
Patrick B
I see :( That is a bit of a bummer. Any known plans for enhancing that or am I using an unusual pattern
Gary Ewan Park
GitVersion uses the history of the entire git repository to make an assertion about the current version number associated with the contents of that repository. As such, no, there are no plans to change away from this.
In terms of usage of GitVersion, the best suggestion would be to move the different pieces of your application, that you want to version separately, into their own repositories.
Patrick B
Does anyone have any examples of applying this to .NET Core projects? I am using the task in Azure DevOps. Will it automatically update my csproj information? There is a checkbox item for "Update AssemblyInfo files" which don't exist anymore by default. Do we specify the csproj instead?
Jorge E. Alvarez
i would like to install it in ubuntu, do you know what do i need to do?
Kim J. Nordmo
@jealvarez easiest way would be through .NET Core
dotnet tool install --global gitversion.tool (this is the only one that is cross-platform compatible now AFAIK)
Jorge E. Alvarez
thank you @AdmiringWorm

@PatrickBig you should had the following to your YAML:
GitVersion.SemVer: ''
GitVersion.AssemblySemVer: ''
GitVersion.MajorMinorPatch: ''
GitVersion.InformationalVersion: ''


  • task: gitversion/setup@0
    versionSpec: '5.x'
    displayName: 'GitVersion setup'

  • task: gitversion/execute@0
    displayName: 'GitVersion execute'

  • task: DotNetCoreCLI@2
    displayName: 'dotnet build'
    command: 'build'
    projects: '$(project)'
    arguments: '/p:Version=$(GitVersion.SemVer)
    --configuration $(buildConfiguration)'

Colin Laws
Hello GitVersion warriors! I am currently working on implementing GitFlow at our company, and there is a lot of confusion here surrounding GitVersion.
mode: ContinuousDelivery
continuous-delivery-fallback-tag: ''
branches: {}
  sha: []
merge-message-formats: {}
I created a tag 0.1.0 on master. Created hotfixes/0.1.1 from master.
At this point, GitVersion was correctly generating me 0.1.1-beta.1+70 (I had a lot of old commits behind this as I was testing).
I performed a commit to hotfixes/0.1.1, which GitVersion asserted as 0.1.1-beta.1+71. Perfect.
Then I created a tag of 0.1.1-beta.1 (I'm following the GitFlow example here https://gitversion.net/docs/git-branching-strategies/gitflow-examples#hotfix-branches)
Running GitVersion asserted 0.1.1-beta.1 as expected.
Colin Laws
I was ready to pull my changes to master. I created a PR of hotfixes/0.1.1 -> master. When running GitVersion on a build for my PR, I am seeing a version of 0.2.0.
Is this due to the fact that GitVersion is looking at what branch is currently checked out in Git, and as I am running in DevOps, my build pipeline is checking out the branch of my pull request to perform a build on that code.
So what I'm imagining going wrong here is that the pull requests branch refs/heads/pull/943/merge is not going to be providing GitVersion with an accurate history to work off of.
Colin Laws
Okay yes, I see the error in my ways. We do not care to even run GitVersion on pull requests, because there's nothing for us to do on PRs. The only reason GitVersion is running on PRs is because we have build validation as a branch policy.
Once we pull that change into master, you would tag master with 0.1.1, and then you'd want to have a release pipeline set up to identify a new tag based on master to release.
So for every release we do for testers on the release branch, we make a tag? Same on hotfix. We would make a hotfix branch, make a change, tag it (fires release), testers give feedback, etc.
David Perfors
Good day, Is there a way to configure GitVersion to use only lowercase characters in the versions? We have an issue in our pipeline that some tasks will force lowercase version numbers for a package, but some bash scripts that use the same packages don't force lowecase.
Mattias Karlsson
NuGetVersionV2 and NuGetPreReleaseTagV2 will always be lowercase. But looking att configuration doesn't seem to be any general case handling you can set