GitTools/GitVersion

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

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.

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

@dnperfors

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

@devlead

NuGetVersionV2 and NuGetPreReleaseTagV2 will always be lowercase. But looking att configuration doesn't seem to be any general case handling you can set
https://github.com/GitTools/GitVersion/blob/fd03acec2d8cea78acbf72e93a0dc48a495450b2/src/GitVersionCore/Model/Configuration/Config.cs#L11

David Perfors

@dnperfors

In our case we are not using NuGetVersionV2 nor NuGetPreReleaseTagV2, but the semver version. We use this version for tagging docker images.

Mattias Karlsson

@devlead

Ok in bash you can lowercase using ,,i.e.

version='AbAbAb'
echo ${version,,}

will output

ababab

so could potentially be a work around in scripts.

David Perfors

@dnperfors

That is indeed a workaround which currently works for me. Thanks for the help :) my bash skills are not that great yet ;)

ForteUnited

@ForteUnited

Hello! I'm using the gitversion/execute@0 in Azure Devops. I would like to get one of the gitversion outputs (SemVer) and set it to a variable in my pipeline for me to use later but I'm not sure how to accomplish this. Can anyone help?

Kim J. Nordmo

@AdmiringWorm

@ForteUnited you can get the giversion output by using ${{ steps.gitversion.outputs.semVer }}

assuming you have set the id of the step to gitversion

ForteUnited

@ForteUnited

ok got it. Thank you @AdmiringWorm

Patrick B

@PatrickBig

Hey all, I'm trying to get GitVersion to install on my build server (linux) but having some trouble. Most likely due to my proxy setup at the company I work at.
If I use the GitTools/setup task I get a timeout. Anything else that needs to reach the internet doesn't seem to have any problems. Any advise?

Another route I was trying to do was to just pre-install on the agent. But using

dotnet tool install -g GitVersion.Tool

Didn't seem to help

The tool would install fine but when running GitTools/execute it says Unable to locate executable file: 'dotnet-gitversion'

ForteUnited

@ForteUnited

So I got the gitversion/execute@0 task working the way I want and I am getting the appropriate variables set. My problem now is that I am using the DotNetCoreCLI@2 to publish a .csproj and its assigning the wrong version/file version to the assembly somehow. I am trying to set it explicitly using /p:Version:$(GitVersion.SemVer) but no matter what I do it seems to be using the GitVersion InformationalVersion value somehow even though I'm not even capturing that output as a variable. what is going on?

Patrick B

@PatrickBig

I solved my problem. I had to add /root/.dotnet/tools to PATH.

Tim Long

@NameOfTheDragon

Dear all, can you help me out with a problem? I'm building .NET Core libraries on Ubuntu Linux, under TeamCity. I don't want to have to install anything on my build agents as far as reasonably possible, so I'm running everything in Docker: TeamCity server, TeamCity agent, MariaDB, all in Docker containers. I also run my dotnet.exe builds in docker containers using TeamCity's docker-in-docker support. I can literally recreate my entire build infrastructure on a new server in about 4 simple commands and I want to preserve that as much as possible. The problem I have is this: GitVersion runs inside the containerized build and doesn't "see" the TeamCity agent. It just thinks it's being run from the dotnet.exe CLI. So while my assemblies all get correctly versioned, the TeamCity integration doesn't work and I just get an incrementing integer build number. Is there a way to get GitVersion to somehow integrate better with TeamCity in this situation? I'd really like my TC build number to show up as the SemVer from GitVersion, maybe with an appended incrementing buidl counter. I just can't seem to think my way through this and I'd really appreciate any suggestions.

Pete-HD

@Pete-HD

Hi all :-) I have a small problem with the configuration from the documentation: https://gitversion.readthedocs.io/en/latest/input/docs/configuration/

There, in the chapter assembly-file-versioning-format the following is given as an example:
assembly-file-versioning-format: '{Major}.{Minor}.{Patch}.{WeightedPreReleaseNumber ?? 0}'

If I use this configuration with the Mainline Mode in our Azure DevOps with the BuildTask GitVersion the following error message appears:
Unable to format AssemblyFileVersioningFormat. Check your format string: 'WeightedPreReleaseNumber ?? 0' is not a member of type 'GitVersion.SemanticVersionFormatValues'

Does anyone have an idea?

I thank you in advance and look forward to your answers. Greetings Pete

Asbjørn Ulsberg

@asbjornu

@Pete-HD, assembly-file-versioning-format: '{Major}.{Minor}.{Patch}.{WeightedPreReleaseNumber ?? 0}' should work. Here's a relevant test: https://github.com/GitTools/GitVersion/blob/f6bc10b11f2ae5218bbeb3fc448b9510fa721aa9/src/GitVersionCore.Tests/Extensions/StringFormatWithExtensionTests.cs#L219-L226

What's not testet, though, is {Major}.{Minor}.{Patch}.{WeightedPreReleaseNumber ?? 0}, which we of course should do. If you can create a PR with that test, that would be great. If not, perhaps I can look into it tonight.

Pete-HD

@Pete-HD

Ok this is strange, because we use it exactly the same way. Unfortunately it does not work. But maybe it's because of the Azure DevOps Extension Task GitVersion.
Thanks for the feedback. I will continue to search for clues. If this does not lead to success, is it wiser to continue asking here or should I open an issue?

Asbjørn Ulsberg

@asbjornu

An issue with a failing test would be ideal, but you're welcome to discuss here as well.

Where communities thrive

People

Repo info

Activity