GitTools/GitVersion

Use convention to derive a SemVer product version from a GitFlow based repository

Nicolai Brogaard

@nmbro

https://github.com/nmbro/travis-gitversion/pull/1/commits/1ac125c6f60086f3bfcc82889730f679fe2f02b9

I tried that on this commit which also failed

Kim J. Nordmo

@AdmiringWorm

@nmbro adding that in a PR don't help, travis (same with appveyor) don't use the yaml file from the pull request, but from the target branch.
So it would need to be added in the repository directly.

You can see the config used on that build here: https://travis-ci.com/github/nmbro/travis-gitversion/jobs/356052758/config

Nicolai Brogaard

@nmbro

updated master branch, and now I'm getting

$ git fetch --unshallow
fatal: --unshallow on a complete repository does not make sense

Kim J. Nordmo

@AdmiringWorm

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

@nmbro

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

@atrauzzi

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

mode: Mainline
increment: Patch
branches:
  develop:
    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

@woernsn

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?
GitVersion 5.3.4.0
Mono JIT compiler version 6.10.0.104

Kim J. Nordmo

@AdmiringWorm

@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

@woernsn

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

@NameOfTheDragon

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

@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

@PepekT

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

@gep13

@PepekT You would create a tag 0.1.0-beta1 and then it should increment

Josef Trejbal

@PepekT

@gep13 So release branch should increment per tag right?

Gary Ewan Park

@gep13

That is how I have always done it.

Trent Scholl

@TrentScholl

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

@AdmiringWorm

@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

@TrentScholl

Running locally

Kim J. Nordmo

@AdmiringWorm

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.

leyshon

@leyshon

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?

pfaustinopt

@pfaustinopt

Hello,

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

@PatrickBig

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

SuperSolution\
\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

@gep13

@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

@PatrickBig

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

@gep13

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

@PatrickBig

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

@jealvarez

i would like to install it in ubuntu, do you know what do i need to do?

thanks

Kim J. Nordmo

@AdmiringWorm

@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

@jealvarez

thank you @AdmiringWorm

pfaustinopt

@pfaustinopt

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

steps:

task: gitversion/setup@0
inputs:
versionSpec: '5.x'
displayName: 'GitVersion setup'
task: gitversion/execute@0
displayName: 'GitVersion execute'
task: DotNetCoreCLI@2
displayName: 'dotnet build'
inputs:
command: 'build'
projects: '$(project)'
arguments: '/p:Version=$(GitVersion.SemVer)
/p:AssemblyVersion=$(GitVersion.AssemblySemVer)
/p:FileVersion=$(GitVersion.MajorMinorPatch)
/p:InformationalVersion=$(GitVersion.InformationalVersion)
--configuration $(buildConfiguration)'

Colin Laws

@ColinLaws

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: {}
ignore:
  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

@ColinLaws

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

@ColinLaws

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.

Where communities thrive

People

Repo info

Activity