GitTools/GitVersion

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

Lazaro

@LazaroOnline

Hi, I was wondering as a developer of NuGet packages, how can GitVersion.Task tap into the msbuild execution without requiring anything else other than the NuGet being added to a project, can someone help me find how it is done?

Alexander Trauzzi

@atrauzzi

Hey everyone! Quick question... I'm configuring my builds and I noticed that every time I commit to master, it increments my major version, rather than patch.

Alexander Trauzzi

@atrauzzi

Is there any way to configure master so that normal commit activity only increments patch?

2 replies

Angela Kim

@angelakim

My GitVersion config is currently set to GitHubFlow using Continuous Delivery with master incrementing on minor instead of the default of patch. I also have assembly-file-versioning-scheme set to MajorMinorPatchTag. When the build validation runs on my pull-request the file version assigned to my *.dll includes the commit number as the tag. However when the pull-request completes and the build on master branch, the tag is returned to 0. How do I make this number unique?

Angela Kim

@angelakim

I'm trying to get to version 1.0.0. I was on 0.1.0 and added +semver: major to my commit but nothing changed. Then in the GitVersion.yml file I set next-version: 1.0.0 and now I'm at version 2.0.0. Can any one help?

Nicolai Brogaard

@nmbro

does GitVersion not support travis?

Gary Ewan Park

@gep13

can you elaborate on what you mean here?

Nicolai Brogaard

@nmbro

yeah let me see if I can set up a reproducible result on a non-private repository

but it's being cloned with git: depth: false on travis

$ git clone  https://github.com/owner/repo.git owner/repo
Cloning into 'owner/repo'...
$ cd owner/repo
$ git fetch origin +refs/pull/33/merge:
From https://github.com/owner/repo
 * branch            refs/pull/33/merge -> FETCH_HEAD
$ git checkout -qf FETCH_HEAD

and gitversion doesn't seem to be able to originating branch:

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

Nicolai Brogaard

@nmbro

and I'm using the docker image: gittools/gitversion:5.3.5-linux-alpine.3.10-x64-netcoreapp3.1

Nicolai Brogaard

@nmbro

https://travis-ci.com/github/nmbro/travis-gitversion

Gary Ewan Park

@gep13

@nmbro this is more a question for @asbjornu or @arturcic but what i will say is that in order to function, GitVersion needs the entire history of the repository. Have you tried running with -output buildserver rather than -output json?

Nicolai Brogaard

@nmbro

nope but I can give it a shot

Nicolai Brogaard

@nmbro

same story - but environment variables are not exposed to docker container - but I which ones would gitversion actually need?

Kim J. Nordmo

@AdmiringWorm

@nmbro I took a quick look at the config that travis-ci reports to use: https://travis-ci.com/github/nmbro/travis-gitversion/jobs/356052758/config

and from the looks of it, it seems it doesn't respect that you use git: depth: false (I don't know if this is something related to using travis-ci.com, as for my own repository on travis-ci.org it respects it), and from looking at the build output from that build it indeed uses a depth flag of 50: https://travis-ci.com/github/nmbro/travis-gitversion/jobs/356052758#L113

Try adding to your yaml file a call to git fetch --unshallow, I believe this should then get gitversion to work for you (since the build didn't respect the git depth value).

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?

Where communities thrive

People

Repo info

Activity