Where communities thrive

  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
Repo info
  • Jun 15 2020 13:06
    arturcic unlabeled #2095
  • Jun 15 2020 13:05
    arturcic opened #2328
  • Jun 15 2020 08:09
    github-actions[bot] commented #2122
  • Jun 15 2020 08:09
    github-actions[bot] commented #2300
  • Jun 15 2020 08:09
    github-actions[bot] commented #2306
  • Jun 15 2020 08:09
    github-actions[bot] commented #2310
  • Jun 15 2020 08:09
    github-actions[bot] commented #2311
  • Jun 15 2020 08:09
    github-actions[bot] commented #2320
  • Jun 15 2020 08:09
    github-actions[bot] commented #2327
  • Jun 15 2020 07:49
    arturcic milestoned #2095
  • Jun 15 2020 07:49
    arturcic demilestoned #2095
  • Jun 15 2020 07:46

    arturcic on 5.3.6


  • Jun 15 2020 07:27
    arturcic demilestoned #2241
  • Jun 15 2020 07:27
    arturcic unassigned #2241
  • Jun 15 2020 07:27
    arturcic demilestoned #2074
  • Jun 15 2020 07:26
    arturcic milestoned #2327
  • Jun 15 2020 07:25
    arturcic demilestoned #2318
  • Jun 15 2020 07:25
    arturcic milestoned #2122
  • Jun 15 2020 07:25
    arturcic labeled #2122
  • Jun 15 2020 07:23
    arturcic demilestoned #2313
Is there a way to dynamically extract a semver tag from a branch name (not the git tag). i.e. having branches release/2.0-preview where preview is used as tag? The only way I see this is having different configurations like for preview/2.0 and release/2.0, but I would prefer to assume all are releases (as they all get released on nuget, but i need the previews tagged as previews, release candidates tagged as release candidates, so that nuget filters them unless the user wants them). Note that I am talking purely of the tag that goes into the build number, not the git tagging mechanism. I am basically trying to avoid having different congiurations and putting the "approoved" tags into the regex. I just tried useBranchName but it turns release/0.3-preview into exactly this.
Ah, got confused. Got it working. useBranchName actually DOES work nicely, including coding the build number as 0001. Any idea how to change this? 10k builds is a little much for a "controlled" release scenario (i.e. not continuous integration for this branch).
When using ContinuousDeployment mode it counts the number of checkins to work out the increment, however many of our devs are used to amending their last commit which then fails to increment the number. Result of this is not being able to push that nuget package. Is there a way to tack on the short sha to the increment to ensure uniqueness?
I'm trying to configure /nonormalize for use in Jenkins, but I can't find the option to use via MSBuild tasks (which is how we're consuming GitVersion)
Is there a way to specify 'nonormalize' via MSBuild property or task?
or to tell GitVersion that it's not on a build server?
Looks like this is being reviewed by GitTools/GitVersion#1031
I managed to force the nonormalize property in msbuild, but it still ends up normalizing and failing for a variety of reasons there-after; is there any way to make the program run the same on a build server as it does locally?
here's the msbuild task I used for disabling it:
  <Target Name="skip normalize" BeforeTargets="GetVersion;GenerateGitVersionInformation;UpdateAssemblyInfo;WriteVersionInfoToBuildLog">
    <Message Importance="high" Text="$(MSBuildProjectName) No-Normalize(Before): $(GitVersion_NoNormalizeEnabled)" />
    <Message Importance="high" Text="$(MSBuildProjectName) No-Normalize(After): $(GitVersion_NoNormalizeEnabled)" />
J.F. Larente

I'm using the yml pipeline version of the task GitVersion@5 - I can't seem to find any documentation with deep examples.

I'm running a VMSS agent pool where not much is installed on the build server. So netcore gets installed with the UseDotNet@2 task.

Hopefully someone has this similar set up and working...

 - task: UseDotNet@2
        packageType: 'runtime'
        version: '2.1.0'
        performMultiLevelLookup: true
- task: GitVersion@5
      runtime: 'core'
      configFilePath: 'GitVersion.yml'
      updateAssemblyInfo: true

Error is ##[error]Error: Unable to locate executable file: 'dotnet'.

6 replies
Artur Kordowski
The gitversion/setup@0 Azure DevOps task have a includePrerelease option, but the task always installs the latest release version. As I figured out the NuGet feed don't contains any pre-release versions. The pre-release versions are only available over the GitHub feed. Is there a way to use the pre-release versions anyway?
Hello, anyone could help with set up GitVersion with AzureDevops?
5 replies
Gary Ewan Park
@ITEFARMAT you may need to provide more information about exactly what you are trying to do, but you have tried, what isn't working, etc.
Daniele Pozzobon
Hi all!
i was looking at the examples of working with gitflow in https://gitversion.net/docs/git-branching-strategies/gitflow-examples specifically the "Minor Release Branches" and don't understand why the version becomes 1.4.0-alpha.1 if it comes from a master that was tagget 1.2.1
1 reply
the same thing happens in "Major Release Branches" and i cannot wrap my head around it
Hayden Hancock
I am working with with on premise Microsoft Visual Studio Team Foundation Server and I am getting an error with the GitVersion Setup task, "self signed certificate in certificate chain." Is this something I can fix without having to do something on the actual server (for which I don't have control over?)
1 reply
Andrew Hodgson
Not sure if this is the right place or I am barking up the wrong tree.
I have recently replaced a custom GitVersion script using 5.1.2 that ran in Azure Devops with the official GitVersion task on version 5.3.7. The prior script just ran GitVersion (without the build server option) and Grepped the output for the FullSemVer and set the build number in Azure Devops accordingly. All the projects have a GitVersion.yml with mode: MainLine and that's it.
With this configuration if the main branch was on version 3.0.1 and I create a feature branch it would get a version number like 3.0.2-newfeature.1 and so on as I added commits. If I created a pull request the version number would continue to increment the same way, i.e, we would get versions like 3.0.2-newfeature.5 and so on.
With the new configuration I end up with versions on the PR builds like 3.0.2-PullRequest1234.5 which is causing problems with some of the tasks, the main one actually being an Azure Artifacts upload step which is complaining about the uppercase string in the version not meeting SemVer requirements.
I would like to restore the old behaviour but can't work out where GitVersion could be getting the branch the PR is actually based from, would prefer to keep the standard GitVersion task if possible.
Any suggestions?
Hayden Hancock
I am trying to implement GitHubFlow workflow and I seem to have it mostly working but for some reason my master branch always gets the tag 'ci' appended when merging from my feature branch. I have the tag for master set as '' (which I think is even the default). Is there a particular reason that this happens? I see that there is a "continuous-delivery-fallback-tag: ci" in the global configuration but I am confused as to what I should do. I am using the mode of ContinuousDeployment.
Pieter Viljoen
Hi, I am switching from Azure DevOps to GitHub Actions. I don't know if GitVersion changed or has a bug, or if I am using it wrong, or if it is because I switched from master to main, but for the life of me I can't get versions to increment using +semver: patch/minor. See https://github.com/ptr727/Utilities/runs/1437057234 for build output, and the project for config. GitVersion is 5.5.1.
10 replies
Hi guys. I am using the GitVersion@5 task on azure devops. I need to access the var GitVersion.SemVer in a different job and don't seem able to. I've tried all the different outputs and explicitly printing it out etc. The reason i have to use it in a different job is that i need to run the gitversion task on a different repo than the repo executing the pipeline. Is there either a way to be able to use it, or a way to run the gitversion task on a different repo than the one executing it? Thanks
Fabio Sforza

hi all, i have a question related to gitversion
i'm just starting to adopt it on a dotnet core project
is it possible to completely avoid the bumping of the prereleasetag? I'm trying to better explain. The guide says, for example, that the version of release branch will be


major: mergeVersion.Major
minor: mergeVersion.Minor
patch: 0
pre-release: {releaseTag.preRelease}.{n} where n = 1 + the number of commits since releaseTag

i would like to have only 1.2.0-alpha

How can i do that?

Josh Close
Why does my SemVer show up as 0.20.3 locally but 0.20.3-origin-master.0 on the build server?
I thought it was because it couldn't use ssh, so I changed the git connection to https with username/token. No change.
Locally it adds -branch.x which is great, but when on master, I don't want that.
Patrik Švikruha
Hi, I have question. I have repository with more nuget packages and I would like to version every package/nuget by own versioning. Is this scenario somehow supported and ideal case, could be ovveride this in csproj or I need to manually ovveride all properties in csproj? I tried set UpdateAssemblyInfo and update things manually but it is not working for sdk like csproj targeted to TFM net472. (GitVersionTask v5.5.1)
Hi, I use the gitversion/setup@0 and gitversion/execute@0 in my azure pipeline on hosted windows agents. The setup task takes quite a long time, like 1-2 minutes for each run and the tool is not cached because its a hosted agent. Anyone that knows how to improve this by custom caching or similiar? From what I understand I am using the new and recommended approach for using gitversion in azure pipeleines.
  • Also if you include the giversion.exe in your repository do you have to ensure its in the path or is there other ways of configuring it through the task (I do not see an option)?
Maxime Beaudry
As I entered in GitTools/GitVersion#2488, some tags were deleted from DockerHub. Would it be easy to bring them back?
Hello, I'm currently testing Azure Pipelines with GitVersion, and I was wondering if it's possible to create the GitVersion.yml file during the execution of the pipeline jobs? This works with Gitlab-CI, but somehow I don't see the process picking up this file (don't see anything related to this file in debug mode).
1 reply
Patrick B
I have a goofy situation. Does anyone have an idea as to why dotnet-gitversion is giving a different version from just using gitversion?
Currently have 5.3.7 installed of just the normal gitversion.exe
I had 5.6 of the gitversion.tool
It seems like the behavior changed
Patrick B
Yeah, when executing gitversion locally I'm getting what I expect. But when running dotnet-gitversion using the Azure Pipelines task is always reports the version as "0.1.0"

@PatrickBig For me in Azure pipeline the config file is not used if I'm not specifying it in the task config, like:
task: gitversion/execute@0
useConfigFile: true
configFilePath: 'gitversion.yml'

Maybe you have the same issue.

I came across an issue using the new GitVersion.MsBuild package - because TargetFramework is being checked in the .props file it's not being picked up by the project configuration (csproj) and requires a targetframework by specified on the command-line or in a Directory.Build.props file. Is this intended?
From my quick glance at the MsBuild package, the TargetFramework checks for including the GitVersionFileExe and GitVersionAssemblyFile paths could be moved to the .targets file, which would then pick up what is already specified in the users csproj. Allowing customization of the GitVersionOutputFile path would be ideal as well, I prefer keeping my source directories free of intermediate files. I wanted to make sure there weren't any specific reasons for these defaults before opening an issue.
Ashleigh Adams
hey guys, is there anyway to tag release candidates at all with tags using GitVersion?
i have a continuous delivery workflow, and tag to release, but if i tag a release candidate (want to avoid release branches) then gitflow fails with:
PackageVersion string specified '0.3.2-rc(no branch)' is invalid.
Ashleigh Adams
to clarify also, it's only an issue when checked out to that tag
Ashleigh Adams
ugh, i found out, it's to do with the branch normalization; is there any way to disable it with GetVersionTask? i can pass -nonormalize and the tool suddenly works, but i can't figure out how to disable it via msbuild...
thanks rubber ducks!
Ashleigh Adams
Patrick B
I have an issue. I figured out my problem where my versions were not being calculated properly. I downgraded the CLI tool to 5.3.7 and everything is working the way I expect now
GitVersion, GitFlow, Azure DevOps, hotfix and pull requests. How do I configure GitVersion to generate the correct version when build pull request of a hotfix? Hotfix build gets version 1.2.3-beta but pull request of that hotfix gets version 1.3.0-PullRequest, I expected it to get 1.2.3-PullRequest
Tim Long

Hey guys, I'm getting an error when building a multi-targetted .NETStandard class library:

C:\Users\Tim.nuget\packages\gitversion.msbuild\5.6.3\tools\GitVersion.MsBuild.targets(110,9): Error MSB4044: The "GenerateGitVersionInformation" task was not given a value for the required parameter "Language".

Any advice on how to deal with this?

Eric Frazer
I just installed GitTools version 0.9.8.X, last updated Jan 5, into Azure DevOps, and am trying to set up gitversion/execute... not working as expected. docs are scant. I'm unclear of how to use this task. I have 'update assemblyinfo files' turned on, but it's unclear if it is supposed to update ALL assemblyinfo.cs files recursively under the main directory, or if I am supposed to point this task to just one directory. Also, it's unclear what to put into "update assembly file". Will that variable take several files or just one? What if I leave it blank? Also, what should go into "working directory path"? a relative directory to the root of the build, like ".\ControlPanel\XXX" ? Not sure.
Whatever the case, when I run it, Azure says, "##[error]Error: Directory not found at .\ControlPanel\ControlPanel. This folder does exact relative to the root.
I have a question. Trying to use Gitversion in mainline mode and the question is - could I prevent getversion to increment a patch number when I create a new branch. So let's say my current master version is 1.0.1 so when I create a new branch from the master - the version in this new branch is 1.0.2. Technically this is the same version really - even the commit is the same.

Hi everyone, I've just updated my solution to use GitVersion.MsBuild (5.6.4) package instead of GitVersionTask (5.5.1) and getting an error when building the solution from command line:

ERROR [01/25/21 18:29:57:89] An unexpected error occurred:
System.IO.IOException: The process cannot access the file '...\gitversion.json' because it is being used by another process. at System.IO.FileStream.ValidateFileHandle(SafeFileHandle fileHandle) at System.IO.FileStream.CreateFileOpenHandle(FileMode mode, FileShare share, FileOptions options) at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access, FileShare share, Int32 bufferSize, FileOptions options) at System.IO.StreamWriter.ValidateArgsAndOpenPath(String path, Boolean append, Encoding encoding, Int32 bufferSize) at System.IO.StreamWriter..ctor(String path, Boolean append, Encoding encoding) at System.IO.File.WriteAllText(String path, String contents, Encoding encoding) at GitVersion.FileSystem.WriteAllText(String file, String fileContents, Encoding encoding) in D:\a\GitVersion\GitVersion\src\GitVersionCore\Core\FileSystem.cs:line 47 at GitVersion.FileSystem.WriteAllText(String file, String fileContents) in D:\a\GitVersion\GitVersion\src\GitVersionCore\Core\FileSystem.cs:line 42 at GitVersion.VersionConverters.OutputGenerator.OutputGenerator.Execute(VersionVariables variables, OutputContext context) in D:\a\GitVersion\GitVersion\src\GitVersionCore\VersionConverters\OutputGenerator\OutputGenerator.cs:line 39 at GitVersion.GitVersionOutputTool.OutputVariables(VersionVariables variables, Boolean updateBuildNumber) in D:\a\GitVersion\GitVersion\src\GitVersionCore\Core\GitVersionOutputTool.cs:line 42 at GitVersion.GitVersionExecutor.RunGitVersionTool(GitVersionOptions gitVersionOptions) in D:\a\GitVersion\GitVersion\src\GitVersionExe\GitVersionExecutor.cs:line 66

is it a known issue?