Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 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

    (compare)

  • 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
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.
Pete-HD
@Pete-HD

I think i found the Problem:

Starting: Version calculate

Task : GitVersion Task
Description : Easy Semantic Versioning (http://semver.org) for projects using Git
Version : 5.0.1
Author : GitVersion Contributors

Help : See the documentation for help

Its Version 5.0.1 from GitVersion Task, but GitVersion Task is Depricated. Maybe we should switch to GitTools.
Many thanks for the help! And forgive me for not having thought of it right away. Sometimes you are quite blind... :-)
Tim Long
@NameOfTheDragon
Does anyone know how to set the TeamCity build number from GitVersion when the build is running inside a Docker container?
Michael Denny
@micdenny

Is there a way to really force a specific version on a specific branch? next-version set the base version, but then a calculation still occurs on it.

My problem is that I need to create an old version of a package to support old stuff, and to avoid having this old stuff sitting on a new version, I was looking for a way to force gitversion to get a tag v0.x.x even if there is already a tag v2.0.0 in place, but if I do that gitversion still calculates from v2.0.0

I've also tried with the ignore but seems the configuration is not read properly the showconfig still return ignore: sha: [] even if I set the commits-before properly

This in fact will become a sort of support branch, that will remain there as far as I will need that old version.

10 replies
awdm
@awdm
Hi, I'm setting up gitversion with Jenkins and want to ask, how using gitversion inside a Docker Container effects this. The documentation says that you need to inject environment variables. Do I need to do something equivalent during the build process, or can I just pretend I'm not on a buildserver at all (which I technically aren't)?
Asbjørn Ulsberg
@asbjornu
@micdenny, have you tried creating a support/0.x branch from the right (old) commit, then tagging and building that?
2 replies
qfaure
@qfaure

Hello Everyone, Is somebody have this error on gitversion 5.3.7
INFO [09/14/20 10:15:02:24] Begin: Normalizing git directory for branch 'refs/pull/2071/head' [09:15:03][Step 3/3] INFO [09/14/20 10:15:02:28] One remote found (origin -> 'git@github.com:betclicgroup/database-sql-instances.git'). [09:15:03][Step 3/3] INFO [09/14/20 10:15:02:28] Skipping fetching, if GitVersion does not calculate your version as expected you might need to allow fetching or use dynamic repositories [09:15:03][Step 3/3] INFO [09/14/20 10:15:02:29] Creating local branch refs/heads/pull/2071/head pointing at 080e678a3e4364b3517a1efbac0554fd4749f51f [09:15:03][Step 3/3] INFO [09/14/20 10:15:02:43] End: Normalizing git directory for branch 'refs/pull/2071/head' (Took: 195.02ms) [09:15:03][Step 3/3] ERROR [09/14/20 10:15:02:86] An unexpected error occurred: [09:15:03][Step 3/3] System.NullReferenceException: Object reference not set to an instance of an object. [09:15:03][Step 3/3] at GitVersion.Extensions.RepositoryExtensions.CreateOrUpdateLocalBranchesFromRemoteTrackingOnes(IRepository repo, ILog log, String remoteName) in D:\a\GitVersion\GitVersion\src\GitVersionCore\Extensions\RepositoryExtensions.cs:line 177 [09:15:03][Step 3/3] at GitVersion.GitPreparer.NormalizeGitDirectory(String gitDirectory, Boolean noFetch, String currentBranch, Boolean isDynamicRepository) in D:\a\GitVersion\GitVersion\src\GitVersionCore\Core\GitPreparer.cs:line 227 [09:15:03][Step 3/3] at GitVersion.GitPreparer.NormalizeGitDirectory(String targetBranch, String gitDirectory, Boolean isDynamicRepository) in D:\a\GitVersion\GitVersion\src\GitVersionCore\Core\GitPreparer.cs:line 141 [09:15:03][Step 3/3] at GitVersion.GitVersionTool.CalculateVersionVariables() in D:\a\GitVersion\GitVersion\src\GitVersionCore\Core\GitVersionTool.cs:line 59 [09:15:03][Step 3/3] at GitVersion.GitVersionExecutor.RunGitVersionTool(GitVersionOptions gitVersionOptions) in D:\a\GitVersion\GitVersion\src\GitVersionExe\GitVersionExecutor.cs:line 56 [09:15:03][Step 3/3] INFO [09/14/20 10:15:02:86] Attempting to show the current git graph (please include in issue): [09:15:03][Step 3/3] INFO [09/14/20 10:15:02:86] Showing max of 100 commits [09:15:03][Step 3/3] INFO [09/14/20 10:15:03:12] * 080e678a 25 minutes ago (HEAD -> pull/2071/head, origin/feature/622, refs/pull/2071/head, feature/622)

Running locally on developer computer no problem.
Running locally on serveur no problem.
Launching by Teamcity => failure.

The problem is very ramdom. Will work sometimes other times no.
For the moment , i found no way to repoduce it locally and debug gitversion.
I see some "similar issue " GitTools/GitVersion#912 , but i see that they are all closed.

Please help us to find a way to solve this problem or at least how to reproduce it locally .

Thanks in advance
Best regards

leyshon
@leyshon
@qfaure I had a similar problem and it was caused by having two branches named identically but with different casing. I.e. master and Master. I couldn't replicate it locally because when you run it locally the normalize section doesn't run. I fixed it by deleting my duplicate branches but you can also use /nonormalize to stop the normalize part running (it ends up thinking the branches are called origin/feature/1234 though as a result for use in metadata)
qfaure
@qfaure
@leyshon thanks you very much for your help. i will try adding the part of /nonormalize in my command line ! for the moment we rollback the version to our previous, We will make some test :)
Nicholas Budd
@anaximander23
when configuring GitVersion for use with Azure DevOps builds, is there a way to use the pull request title in the label? We're getting a lot of builds as things like 2.1.0-pullrequest0017.003 which makes it hard to quickly spot which is which
would be nice if they could be named using the PR title or the name of the branch that the PR is for
is this something that can be done from config?
Kim J. Nordmo
@AdmiringWorm

@anaximander23 I think it may be possible, see the configuration documentation here: https://gitversion.net/docs/configuration

I assume having the following configuration would allow what you want to be possible:

branches:
  pull-request:
    regex: ^(pull|pull\-requests|pr)[/-]
    mode: ContinuousDelivery
    tag: '{BranchName}'
    increment: Inherit
    prevent-increment-of-merged-branch-version: false
    tag-number-pattern: '[/-](?<number>\d+)[-/]'
    track-merge-target: false
    tracks-release-branches: false
    is-release-branch: false

Do note that I haven't tested this myself, so I got no idea if it works or not.

Nicholas Budd
@anaximander23
I'll give it a try, thanks
I suspect there's something weird going on where DevOps silently creates temporary branches to attempt the merge, or something
but I guess I'll find out
Nils Andresen
@nils-a
Hi. I have recently switched from version 3.6.5 of GitVersion to 5.3.7 (using the net global tool) the version-detection was flawless before but now the release-versions are no longer recognized.
I.e. I tagged the main-branch using a tag '0.3.0' and expected GitVersion to calulate a version of '0.3.0' but instead it was '0.4.0-main0001'.
I have never had a gitversion.yml before. Looking at gitversion /showconfignothing there suggests that my main-as-master branch setup should have ever worked. (then again, neither does it look like it when I used /showconfig previously)
Am I missing something?
1 reply
NetTecture
@NetTecture
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.
NetTecture
@NetTecture
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).
greengumby
@greengumby
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?
James
@bondpp7-2
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)
James
@bondpp7-2
Is there a way to specify 'nonormalize' via MSBuild property or task?
James
@bondpp7-2
or to tell GitVersion that it's not on a build server?
James
@bondpp7-2
Looks like this is being reviewed by GitTools/GitVersion#1031
James
@bondpp7-2
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)" />
    <PropertyGroup>
      <GitVersion_NoNormalizeEnabled>true</GitVersion_NoNormalizeEnabled>
      <GitVersion_NoFetchEnabled>true</GitVersion_NoFetchEnabled>
    </PropertyGroup>
    <Message Importance="high" Text="$(MSBuildProjectName) No-Normalize(After): $(GitVersion_NoNormalizeEnabled)" />
  </Target>
J.F. Larente
@jeanfrancoislarente

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
      inputs:
        packageType: 'runtime'
        version: '2.1.0'
        performMultiLevelLookup: true
- task: GitVersion@5
    inputs:
      runtime: 'core'
      configFilePath: 'GitVersion.yml'
      updateAssemblyInfo: true

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

6 replies
Artur Kordowski
@akordowski
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?
Mateusz
@ITEFARMAT
Hello, anyone could help with set up GitVersion with AzureDevops?
5 replies
Gary Ewan Park
@gep13
@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
@danielepo
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
@haydenhancock
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
@adhodgson1
Hi,
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?
Thanks.
Andrew.
Hayden Hancock
@haydenhancock
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
@ptr727
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
spersov
@spersov
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
@fsforza

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

1.2.0-alpha1

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?
Thanks

Josh Close
@JoshClose
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
@PadreSVK
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)
mnordlindh
@mnordlindh
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)?