by

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 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
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
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.
Nicholas Budd
@anaximander23
yeah, I get that it's the build metadata suffix
my point is that it previously wasn't using that in the git tags
and now it is