GitTools/GitVersion

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

Matthias Koch

@matkoch

google

this one works, but any other link is broken... i noticed there's a new website, but probably you're missing a couple of redirects

Thomas Skardal

@tskardal

I have some issues with builds getting a wrong version number. These are builds done by appveyor, and gitversion.yml contains:

assembly-versioning-scheme: MajorMinorPatchTag
mode: ContinuousDelivery
branches: {}
ignore:
  sha: []
  commits-before: 2019-04-01T09:00:00

When the latest tag (tagged on master) is built though, it somehow decides to increment, and we end up with a bumped minor version.

If I checkout the tag locally and run gitversion (on macos, appveyor build is windows) it works fine. I'm not sure how to attack this.

FWIW: the appveyor image contains this version 5.1.3+Branch.master.Sha.bef8ebc0b62b3ddd0cdafe09b66d68bbfcaf90d5

1 reply

Peder Husom

@hayer

Using GitVersion via Github actions. I can see that it outputs the version information, but the steps.<step id>.outputs.nuGetVersionV2 seems to always be empty (same goes for the other variables). Id is set, steps are inside the same job, using gittools/actions/gitversion/execute@v0.9.9.. Any pointers to what im doing wrong?

    steps:
    - name: Checkout
      uses: actions/checkout@v2
      with:
        fetch-depth: 0
    - name: Install GitVersion
      uses: gittools/actions/gitversion/setup@v0.9.9
      with:
        versionSpec: '5.x'
    - name: Determine Version
      id: gv
      uses: gittools/actions/gitversion/execute@v0.9.9
      with:
        useConfigFile: true
        additionalArguments: '/showConfig'

    - name: Display GitVersion outputs
    # .... prints all the steps.gv.semVer etc -- which are all empty..

Using echo "BuildMetaData: ${{ steps.gv.outputs.buildMetaData }}" to print the values. Tried without the spaces after {{ and before }} as well.

Kim J. Nordmo

@AdmiringWorm

@hayer did you try without the additionalArguments argument?
Just a thought, maybe it prevents the outputs being set

Abhishek Tripathi

@AbhishekTripathi

I am trying to use gitversion in my CI/CD process. Looking at the documentation, it appears the only version for dotnet core binaries is dotnet-gitversion. Since the sdk style projects do not contain any AssemblyInfo.cs files, is there a command line switch to update the project file and have the version incremented there? Possibly someone can point me to some link. I can't use build server variable approach at the moment using /output switch.

Abhishek Tripathi

@AbhishekTripathi

dotnet-gitversion.exe /updateassemblyinfo doesn't work with dotnet core projects because there is no AssemblyInfo.cs and adding the file specifically for gitversion is not good because people may forget to do it for new projects.

Gaute Løken

@gautelo

I don't understand the repository structure. Could somebody please give me some directions either here or some docs explaining how to build and run tests? Basically I am missing something when it comes to repositories that aren't a simple open vs solution and build. There are scripts and things and I don't know what to run or where to look.

Gaute Løken

@gautelo

Ok. So I see it's using something called Cake. I guess that means I need to learn that tool to be able to do things.. barrier to entry.. :(

Gary Ewan Park

@gep13

@gautelo the build process should be as simple as running the ./build.ps1 file in the root of the repository. Are you saying that this isn't working?

This is the process that is currently executed on the AppVeyor CI for the project.

Gaute Løken

@gautelo

The first thing it says if I run that is that it's supposed to be run in the CI scenario, and not for local dev

If I disregard that and run it anyway I'm getting some file-access error.

@gep13 I also have to set the execution policy
Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass

GitVersion-build-output.log

@gep13 uploaded my output

Gaute Løken

@gautelo

ohh.. when I right-click my console it outputs a lot of more Access to the path (in .git folder) kind of errors such as this:

Error: One or more errors occurred. (Access to the path 'C:\Dev\ref\GitVersion\src\GitVersion.App.Tests\bin\Release\netcoreapp3.1\TestRepositories\076332c9-80cc-4247-8392-de22ccf6981c\.git\objects\09\ce06bf80bebdb9f95ea70d37b91f8a5a83c307' is denied.)

Access : The term 'Access' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that 
the path is correct and try again.
At line:1 char:38
+ Error: One or more errors occurred. (Access to the path 'C:\Dev\ref\G ...
+                                      ~~~~~~
    + CategoryInfo          : ObjectNotFound: (Access:String) [], CommandNotFoundException
    + FullyQualifiedErrorId : CommandNotFoundException

Gary Ewan Park

@gep13

I have just tried the same ./build.ps1 file on my machine here, and the Cake build runs as expected on my machine, so I don't have a good answer as to why you are getting permission errors when you try to run the build. :-(

Are you also getting errors when trying to run the build in Visual Studio?

Gaute Løken

@gautelo

ok. Thank you. I will try to take a fresh clone.

Gaute Løken

@gautelo

GitVersion-build-output.log

Ok. Seems the access issues were from previous attempts to run things. Had a bunch of console processes I couldn't account for. Restart and fresh clone allowed me to build. So now it cleans and builds successfully, but there are a bunch of test-failures. I'm guessing that's not normal? Here is the new output.

I'm on the main branch btw

Gaute Løken

@gautelo

When I run again it once again fails on clean and access paths.

If I were to venture a guess, the successfull build leaves a non-zero exit code and then tests are failing because the exit code is not reset. Why running another build is failing on access might be because those previous tests leave some processes holding onto files running blocking the next attempt.

Gaute Løken

@gautelo

Seems hanging processes isn't actually the issue. I've found that if I delete everything under C:\Dev\ref\GitVersion\src\GitVersion.App.Tests\bin\Release\netcoreapp3.1\TestRepositories I can rerun the build (with tests still failing as before).

Gaute Løken

@gautelo

Attempted running in a 32 bit powershell, but same results.

cedricmendelin

@cedricmendelin

Hey guys
I started using gitversion and the tools looks really promising. Still I am a little bit struggling with integration. So we are using AzureDevops and we hat that .NETStandard2.0 and .NETFramework 4.72 Solution (Visual Studio Extension). The Task for Buildpipeline is working fine but I would also like to have versioning on a local build. I start using the Nuget Packages but the only thing which is working is the depricated GitVersionTask nuget Package, the newer ones also throw errors during builds.
Am I doing something wrong or is the gitversion tool not suited for the given setup with .NETStandard 2.0 and net472?

Gaute Løken

@gautelo

Just wanna pop by again, to say thanks for the excellent IntegrationTests. They do a very good job of communicating intent. Thanks! <3

Gaute Løken

@gautelo

The cli has a /config option, is there a similar option for the msbuild tasks? A build property perhaps?

Gaute Løken

@gautelo

In my case I just wanted to go one folder out, so the following workaround worked for me:

  <Target Name="SetGitVersionConfigFile" BeforeTargets="RunGitVersion" Condition="!$(GitVersion_ToolArgments.Contains('-config'))">
    <PropertyGroup >
        <GitVersion_ToolArgments>$(GitVersion_ToolArgments) -config ../GitVersion.yml</GitVersion_ToolArgments>
    </PropertyGroup>
    <Message Text="GitVersion_ToolArgments: $(GitVersion_ToolArgments)" Importance="high" />
  </Target>

James P Chadwick

@jamespchadwick

Hi all! Doing a little weekend experimentation with GitVersion to start implemeting Semantic Versioning in my projects. I took one of my projects and added GitVersion to the csproj file using:

dotnet add package GitVersion.CommandLine --version 5.6.8

I can see that the package reference has been included in my .csproj file:

    <PackageReference Include="GitVersion.CommandLine" Version="5.6.8">
      <IncludeAssets>runtime; build; native; contentfiles; analyzers; buildtransitive</IncludeAssets>
      <PrivateAssets>all</PrivateAssets>
    </PackageReference>

But when I try to invoke GitVersion in the command line I get an error saying its not a recognized. I've tried tons of different variations and none of them work.

> gitversion
>gitversion.exe
>dotnet-gitversion
>dotnet-gitversion.exe

I wanted to go this route as opposed to installing it as a global tool because I'd eventually like to use the same scripts to build and release on my local machine and on my CI/CD server and I dont want to have to remember to install something globally every time I start working on a new machine or a I add a new developer to my project

Anyone have any insights or suggestions? Is using GitVersion non-globally even a supported options?

David Keaveny

@davidkeaveny

Has anyone tried using the GitVersion metarunner with TeamCity Cloud Beta? If I generate the version number in TeamCity on-premise, then everything works fine; if I try to generate the version number against the same repo/branch in TeamCity Cloud Beta, I get the following exception:

 System.NullReferenceException: Object reference not set to an instance of an object.
       at GitVersion.GitObject..ctor(GitObject innerGitObject)
       at GitVersion.Commit..ctor(Commit innerCommit)
       at GitVersion.GitRepository.<>c__DisplayClass27_0.<FindMergeBase>b__0()
       at Polly.Policy`1.<>c__DisplayClass11_0.<Execute>b__0(Context ctx, CancellationToken ct)
       at Polly.Retry.RetryEngine.Implementation[TResult](Func`3 action, Context context, CancellationToken cancellationToken, ExceptionPredicates shouldRetryExceptionPredicates, ResultPredicates`1 shouldRetryResultPredicates, Action`4 onRetry, Int32 permittedRetryCount, IEnumerable`1 sleepDurationsEnumerable, Func`4 sleepDurationProvider)
       at Polly.Retry.RetryPolicy`1.Implementation(Func`3 action, Context context, CancellationToken cancellationToken)
       at Polly.Policy`1.Execute(Func`3 action, Context context, CancellationToken cancellationToken)
       at Polly.Policy`1.Execute(Func`1 action)
       at GitVersion.Helpers.RetryAction`2.Execute(Func`1 operation)
       at GitVersion.GitRepository.FindMergeBase(ICommit commit, ICommit otherCommit)
       at GitVersion.RepositoryStore.FindMergeBase(ICommit commit, ICommit mainlineTip)
       at GitVersion.VersionCalculation.BaseVersionCalculator.FixTheBaseVersionSourceOfMergeMessageStrategyIfReleaseBranchWasMergedAndDeleted(IEnumerable`1 baseVersions)
       at GitVersion.VersionCalculation.BaseVersionCalculator.GetBaseVersion()
       at GitVersion.VersionCalculation.NextVersionCalculator.FindVersion()
       at GitVersion.GitVersionCalculateTool.CalculateVersionVariables()
       at GitVersion.GitVersionExecutor.RunGitVersionTool(GitVersionOptions gitVersionOptions)

The Sharp Ninja

@sharpninja

@davidkeaveny I have the same problem on Azure DevOps

INFO [04/24/21 14:46:13:84] Dumping commit graph: 
INFO [04/24/21 14:46:13:87] * 83e0c0f 6 minutes ago  (HEAD -> azure-pipelines, origin/azure-pipelines, origin/83e0c0fd2ea6f5822dc53f79d34be2dd20293841, 83e0c0fd2ea6f5822dc53f79d34be2dd20293841)
* 677a190 70 minutes ago  (677a190f3574bf4f648ec096c2aa8c6cf2da5c97)
*   f38a4b8 77 minutes ago  (f38a4b84b9a4256c61641145b49ee83e298de00d)
|\  
| * 50977fb 79 minutes ago  (origin/main, main)
* | 3f93c73 77 minutes ago  (3f93c73e6ae856bf1fb512c7a790641717506a47)
* | 1f6632c 82 minutes ago  (1f6632c3f41ff79ad56dd8f1b56e0a40a49ed510)
|\| 
| * 1593c4a 84 minutes ago 
* | 64363c1 2 hours ago  (64363c1681b10b92c1bcff4eef888e1cdef0b295)
* | 615b05d 2 hours ago 
* | 4c3a9fa 2 hours ago  (4c3a9fa836a1c194c9205390f33fd250e2945cc5)
* | 899f173 2 hours ago 
* | 2049b32 2 hours ago 
|\| 
| * 0ebb401 2 hours ago 
* | e70e48e 2 hours ago 
|\| 
| * c345bde 5 hours ago 
| * 675de41 20 hours ago 
| * 8788539 20 hours ago 
* | 880d261 2 hours ago 
* | c524cdc 2 hours ago 
* | f23302e 2 days ago 
|/  
* c5fec36 2 days ago 
* b7772ab 2 days ago 
* d7cc1bb 2 days ago 
* ae9d7d4 2 days ago  (origin/master, master)

INFO [04/24/21 14:46:13:87] Working directory: /home/ninja/myagent/_work/1/s
INFO [04/24/21 14:46:13:89] Project root is: /home/ninja/myagent/_work/1/s/
INFO [04/24/21 14:46:13:89] DotGit directory is: /home/ninja/myagent/_work/1/s/.git
INFO [04/24/21 14:46:13:98] Using latest commit on specified branch
INFO [04/24/21 14:46:13:99] No branch configuration found for branch azure-pipelines, falling back to default configuration
INFO [04/24/21 14:46:13:99] Begin: Attempting to inherit branch configuration from parent branch
  INFO [04/24/21 14:46:14:00] Begin: Finding branch source of 'azure-pipelines'
    INFO [04/24/21 14:46:14:01] Begin: Finding merge base between 'azure-pipelines' and 'main'.
      INFO [04/24/21 14:46:14:02] Found merge base of 50977fb Killed package lock.
      INFO [04/24/21 14:46:14:02] Merge base of azure-pipelines' and 'main is 50977fb Killed package lock.
    INFO [04/24/21 14:46:14:03] End: Finding merge base between 'azure-pipelines' and 'main'. (Took: 14.69ms)
    INFO [04/24/21 14:46:14:03] Begin: Finding merge base between 'azure-pipelines' and 'master'.
    INFO [04/24/21 14:46:14:03] End: Finding merge base between 'azure-pipelines' and 'master'. (Took: 1.40ms)
  INFO [04/24/21 14:46:14:03] End: Finding branch source of 'azure-pipelines' (Took: 24.34ms)
  INFO [04/24/21 14:46:14:03] End: Attempting to inherit branch configuration from parent branch (Took: 34.42ms)
  INFO [04/24/21 14:46:14:04] Attempting to show the current git graph (please include in issue): 
  INFO [04/24/21 14:46:14:04] Showing max of 100 commits
  INFO [04/24/21 14:46:14:04] * 83e0c0f 6 minutes ago  (HEAD -> azure-pipelines, origin/azure-pipelines, origin/83e0c0fd2ea6f5822dc53f79d34be2dd20293841, 83e0c0fd2ea6f5822dc53f79d34be2dd20293841)
* 677a190 70 minutes ago  (677a190f3574bf4f648ec096c2aa8c6cf2da5c97)
*   f38a4b8 77 minutes ago  (f38a4b84b9a4256c61641145b49ee83e298de00d)
|\  
| * 50977fb 79 minutes ago  (origin/main, main)
* | 3f93c73 77 minutes ago  (3f93c73e6ae856bf1fb512c7a790641717506a47)
* | 1f6632c 82 minutes ago  (1f6632c3f41ff79ad56dd8f1b56e0a40a49ed510)
|\| 
| * 1593c4a 84 minutes ago 
* | 64363c1 2 hours ago  (64363c1681b10b92c1bcff4eef888e1cdef0b295)
* | 615b05d 2 hours ago 
* | 4c3a9fa 2 hours ago  (4c3a9fa836a1c194c9205390f33fd250e2945cc5)
* | 899f173 2 hours ago 
* | 2049b32 2 hours ago 
|\| 
| * 0ebb401 2 hours ago 
* | e70e48e 2 hours ago 
|\| 
| * c345bde 5 hours ago 
| * 675de41 20 hours ago 
| * 8788539 20 hours ago 
* | 880d261 2 hours ago 
* | c524cdc 2 hours ago 
* | f23302e 2 days ago 
|/  
* c5fec36 2 days ago 
* b7772ab 2 days ago 
* d7cc1bb 2 days ago 
* ae9d7d4 2 days ago  (origin/master, master)

INFO [04/24/21 14:46:13:84] Dumping commit graph: 
INFO [04/24/21 14:46:13:87] * 83e0c0f 6 minutes ago  (HEAD -> azure-pipelines, origin/azure-pipelines, origin/83e0c0fd2ea6f5822dc53f79d34be2dd20293841,

Jim-with-a-J

@Jim-with-a-J

hi folks, I wonder if anyone can offer any suggestions as to why our build machine might return a different version to my dev machine. The server doesn't have a shallow clone. Both are using GitVersion 5.5.0 and they report identical configuration with /showconfig. They also report the exact same SHA as the version source :( The "server" (running Windows 7) returns 5.1.0 while my machine (Windows 10) returns 5.0.16

Gary Ewan Park

@gep13

@Jim-with-a-J can I suggest that you run gitversion /diag on both machines? This should provide additional information about "how" the version number was asserted on both machines, and from there, it will hopefully guide you in the right direction.

Jim-with-a-J

@Jim-with-a-J

@gep13 thanks, I have actually just been looking at a diff of /diag from both machines. It starts diverging almost immediately - both say HEAD is a merge commit and likely a pull request, but they both pick a different branch as the likely base for it

(the commit in question merges from master into the branch we're trying to build, but the build VM sees this as using master as the base, while my machine sees the opposite). I'm not sure if this matters, I'm still at the start of the logs

Gary Ewan Park

@gep13

@Jim-with-a-J which CI system are you running on? Are you running the exact same gitversion command locally as on the server, or are you using the /output buildserver option?

Jim-with-a-J

@Jim-with-a-J

To investigate this problem, I'm running the exact same command on both machines manually, /diag is the only parameter.

Gary Ewan Park

@gep13

And just to confirm, have you deleted the cached version of the asserted version number from within the .git folder? This may causes problems if not cleared out

Jim-with-a-J

@Jim-with-a-J

this is not something I have done in the past, should I just delete the entire gitversion_cache folder?

(dinner time here, thanks for your help and I will get back with results a little later)

Gary Ewan Park

@gep13

There is no harm in doing that. GitVersion will put these files back if/when needed. Clearing them out on both machines will mean that you are getting the same execution each time (assuming that the history/state of the repository is the same on each machine)

Jim-with-a-J

@Jim-with-a-J

thanks @gep13, clearing out the cache didn't make a difference, but I tried a fresh clone on both systems, and now my version matches the server's. I guess my repository has some cobwebs from a lifetime of abuse :)

Gary Ewan Park

@gep13

Depending on how GitVersion is invoked, it can make some changes to the repository (a process known as normalization) where it attempts to ensure that all required information (commits, tags, etc) are present in the local clone.

Glad to hear that you got it working though!

Alessandro Surace

@zioalex_gitlab

Hi All

Looks like I am not able to raise the major/minor/patch version when I like to do it.

I did with a commit message like this: "+semver: minor" in a feature branch but the minor is never updated.
I am running this locally and on Azure DevOps the result is the same.
This is the message of the feature build "#5.1.0-add-update-detection-stage.1+20 +semver: minor"
While this is then I merge to master:
"#5.1.0+24 Merged PR 833: Increase minor...Maybe"
Either way no minor increment.

Amaury Levé

@Evangelink

Hi there, I have just started to use gitversions and I have a question. I have initialized my yaml file as described in the documentation and set up the next version to 1.0.0. I have done a couple of PRs which get the expected version. I have then added a 1.0.0 tag to one of my commit and now gitversions mark the new build with v1.0.1+XXX is it expected? I would have been expecting to see v2.0.0 or v1.1.0.

Where communities thrive

People

Repo info

Activity