Where communities thrive

Join over 1.5M+ people
Join over 100K+ communities
Free without limits
Create your own community

Explore more communities

GitTools/GitVersion

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

People

Repo info

Activity

Jun 15 13:06

arturcic unlabeled #2095
Jun 15 13:05

arturcic opened #2328
Jun 15 08:09

github-actions[bot] commented #2122
Jun 15 08:09

github-actions[bot] commented #2300
Jun 15 08:09

github-actions[bot] commented #2306
Jun 15 08:09

github-actions[bot] commented #2310
Jun 15 08:09

github-actions[bot] commented #2311
Jun 15 08:09

github-actions[bot] commented #2320
Jun 15 08:09

github-actions[bot] commented #2327
Jun 15 07:49

arturcic milestoned #2095
Jun 15 07:49

arturcic demilestoned #2095
Jun 15 07:46

arturcic on 5.3.6

(compare)
Jun 15 07:27

arturcic demilestoned #2241
Jun 15 07:27

arturcic unassigned #2241
Jun 15 07:27

arturcic demilestoned #2074
Jun 15 07:26

arturcic milestoned #2327
Jun 15 07:25

arturcic demilestoned #2318
Jun 15 07:25

arturcic milestoned #2122
Jun 15 07:25

arturcic labeled #2122
Jun 15 07:23

arturcic demilestoned #2313

henrik eriksson

@henrik_GJ_Esson_twitter

I realised I missed out on a sentence in semantic versioning, that patch set increases even though there is no change in the public api

So I will try out according to your suggestion. Hope that gitVersion will look into root repository repo for the yml file, since the cake tool folder is in .gitignore

henrik eriksson

@henrik_GJ_Esson_twitter

Guess I must set the workingDirectory for gitversion my repoRootPath and have the gitversion.yml there...

henrik eriksson

@henrik_GJ_Esson_twitter

So there is now a gitVersion.yml file. I still think believe that it should be forced to change patch set according to semantic versioning for internaldevelopment. And for release branches, using "next version" is great as a base.

thanks for the help

I wonder one more thing, If I use continous delivery mode for non release branches to increase patch version. For which branch merges do the patch set increase?

henrik eriksson

@henrik_GJ_Esson_twitter

Having issues with gitVersion taking long time to determine version, searching through all merge bases. Now testing on development branch. How to remedy this? Let's say e.g. development branch should only reference development branch or what is contained within the the master branch

henrik eriksson

@henrik_GJ_Esson_twitter

one approach in CI environment would be to only checkout the target branches and have gitVersion trust the content in the git repo.

For local builds it can then however still be slow. But enforcing a workflow to increment the version only in central CI environment, there could always be the approach of not executing gitVersion locally (on the entire repo)

henrik eriksson

@henrik_GJ_Esson_twitter

When generating the version, and not having it stored in gitrepo, how to backtrack from installer to the code? always create git tag with the majorMinorPatch? or use sha1?

henrik eriksson

@henrik_GJ_Esson_twitter

Let's say using continous deployment mode over time and generating new versions, will it be slow when there is no gitTag to use as base for the version calculation after a while. Let's say that there are e.g. 300 commits without any gitTag. Increasing patch set on each one.

henrik eriksson

@henrik_GJ_Esson_twitter

Noticing that to find the base version, checking through all the possible merge points to calculate it, on feature branch takes ~20minutes.

henrik eriksson

@henrik_GJ_Esson_twitter

Noticing that the setting "tracks-release-branches:true" on development branch caused the search mayhem (taking 20 minutes instead of below 1 minute). Luckily we are not following GitFlow, so just to disable that. The behavior was noted on feature branch, branched of from development.

PinkyBrain

@PinkyBrain_gitlab

In versioning the head in my develop branch, gitversion is finding the previous commit as base, which is tagged, but returning that same version (doesnt increment anything), anyone have an idea why? diag looks like this: Base version used: Git tag 'v0.3.0-alpha-0001': 0.3.0-alpha-0001 with commit count source 62ac01da5c9805fcf101d534c07054dfc6040292 (Incremented: 0.3.0-alpha-0001)

henrik eriksson

@henrik_GJ_Esson_twitter

What is your default increment type? Have you setup GitVersion.yml file? How does the configuration look?

Michael Broadbent

@mikebro

Hello, I was looking at using GitVersion in a docker container. I don't see anything about docker in the docs and links of the tags in docker hub description are broken. Is it recommended to use, or not very used/supported? (https://hub.docker.com/r/gittools/gitversion)

Simon Novak

@snovak7

Depending on the version, you need mono or dotnet, so it’s no big deal, as you woul install it otherwise

Asbjørn Ulsberg

@asbjornu

@mikebro, GitVersion in Docker works. It’s a bit awkward since getting environment variables out of a container is hard, but it’s doable.

Michael Broadbent

@mikebro

Alright, thanks. I was thinking that docker might make settings up the CI servers a bit more straight forward but I'm going to stick with Chocolatey for now

Josh Williams

@jackjwilliams

We've just started using release/ branches as we are out of development mode and going to production. The first one was release/2.1.0. I asked everyone to branch off of this for fixes. So we use our normal fix/license-bug type branches. But GitVersion freaked out, saying it couldn't find the source branch. When I add a fix header to GitVersion.yml, with source-branches of release, it still builds 2.2.0-license-bug1, when I was expecting 2.1.0-license-bug2 (since it was branched from release/2.1.0. Am I doing this wrong?

Or is there a recommended branching strategy for bugfixes off of release/* branches?

henrik eriksson

@henrik_GJ_Esson_twitter

If you have specified in your yml file to increment minor, then this is the expected behavior. If you specify to increment patch, then instead gitversion will give 2.1.1

GitVersion will calculate the next version for you. This is by design

If you would use GitTag as bearer of version information, the commit which has the actual gittag with version information will dhow that information as version. The following commit(s) will have the calculated next version

Josh Williams

@jackjwilliams

The branch increment strategy is inherit. Since the /diag outputs that it is defaulting to the develop as a source, it's using develops Minor increment I guess.

But why does it keep using develop when I have explicitly said source-branches: ['release'] ?

Geert van Horrik

@GeertvanHorrik

Hi all, I am trying to plan an upgrade to the latest version, and I heavily depend on the dynamic repositories stuff. I am doing a few tests and experience some exceptions. Will try to put the progress here while I work my way through them

Geert van Horrik

@GeertvanHorrik

See GitTools/GitVersion#1758, that should "fix it all"

Artur

@arturcic

@/all Version 5.0.0 of the GitVersion has just been released, https://www.nuget.org/packages/GitVersion.Tool, https://github.com/GitTools/GitVersion/releases/tag/5.0.0

Simon Novak

@snovak7

Great news

does this apply also to a Task ?

Its seems yes :) cool

Artur

@arturcic

yes, we include the task as well

Geert van Horrik

@GeertvanHorrik

Party time, well done everyone!

Artur

@arturcic

Yeah, it was a huge release

Thank you everyone for your contribution!

Asbjørn Ulsberg

@asbjornu

@arturcic, fantastic! Great job! 🎉

Artur

@arturcic

Thank you

Nicholas Budd

@anaximander23

quick query regarding the use of GitVersion in builds

specifically, Azure DevOps Pipelines

(using the "classic" editor; I haven't moved this to yaml yet)

I've been using GitVersion on this build for a while and it works great

recently, it seems to have changed how it's tagging the commits when the build is done

it used to come out in the format 2.1.1

now it comes out as 2.1.1+5

how do I get it to stop adding the suffix?

as far as I can tell from the docs, something like $(GitVersion_NuGetVersionV2) should work, but if I use that as the option it prints that as a literal string

and yes, I've added /output buildserver to the additional args

Mattias Karlsson

@devlead

+5 is likely the revision number, each build needs to be unique, tried $(GitVersion.NuGetVersion) mentioned at https://gitversion.readthedocs.io/en/latest/build-server-support/build-server/tfs-build-vnext/

I'm guessing though as I use Cake or MSBuild task myself.