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
Igor Artamonov
@splix
I wanted to try GitVersion tool in our project, to tag builds during CI. We use CircleCI and Travis, and none of them comes with GitVersion preinstalled. I was trying to find a release for non-windows os, but don't see any. 'apt-get install gitversion' can't find it too. Am I missing something, or how people use it with circleci/travis?
Kim J. Nordmo
@AdmiringWorm
most projects I've seen make use of the GitVersion.Commandline nuget package (which requires mono on non-windows systems).
There is also a .NET Core global tool called GitVersion.Tool that can also be used (no stable release of this one yet though)
@splix ^^
Igor Artamonov
@splix
Can you please to point to any of such project? open soruce I mean. want to take a look at their CI configs
because I have no idea what is nuget package actually :) and how to install it
ah, maybe I’ve found a project with such travis config. trying now
Kim J. Nordmo
@AdmiringWorm
I see. The projects I've seen using it, mostly build on Windows (some do on Linux as well), and all of them makes use of something called Cake to orchestrate the build, which then pulls down the nuget packages the owners want to use.
This may not apply to you though unfortunately
not seen anyone using the cmd directly yet though.

ah, maybe I’ve found a project with such travis config. trying now

Good luck

Igor Artamonov
@splix
I've found a .travis file on github with following line dotnet tool install -g GitVersion.Tool --version '4.0.1-*’, I guess it does what I want. Though I don’t see any calls of GitVersion in that repo, that’s strange
Kim J. Nordmo
@AdmiringWorm
They probably makes use of dotnet gitversion or dotnet-gitversion somewhere in the repo. Most likely in a build script (would at least be my guess)
Igor Artamonov
@splix
Ah, you’re right! they do dotnet gitversion I’ve missed that line. Thank you!
Kim J. Nordmo
@AdmiringWorm
:+1:
Igor Artamonov
@splix
it seems that dotnet command works only if you build csharp project :(
Kim J. Nordmo
@AdmiringWorm
oh right, I completely forgot about that. You probably would need to use the mono edition of gitversion then.
Did some digging around, and found something that may be of some use to you: https://sedders123.me/2017/07/28/install-gitversion-on-ubuntu/
I haven't tested that article though, as I'm not using ubuntu (which I believe travis uses)
Igor Artamonov
@splix
Thank you!
Kim J. Nordmo
@AdmiringWorm
no problem, hope that helps you at least a little
Calvin Dallmore
@aeos
@splix not that this is what you want, but if you use dotnet cake with GitVersion.Tools then you can use GitVersion in a build setup and use the versioning for other project types.
henrik eriksson
@henrik_GJ_Esson_twitter
I'm using the default settings in gitVersion, and the approach to determine the next version based on the commit message.
One thing is strange: '+semver: Patch' and '+semver: Skip' ends up in the same result
that patch number is increased
It should not be increased on skip, right?
henrik eriksson
@henrik_GJ_Esson_twitter
is there a smoother way to get gitVersion to calculcate the new version. instead of tampering with the commit message?
Gary Ewan Park
@gep13
@henrik_GJ_Esson_twitter I use gitflow, and I have never needed to tamper with commit messages to bump version number.
You have an option to specify the "next" version number in the configuraiton yml file
henrik eriksson
@henrik_GJ_Esson_twitter
THen the next version is automatically defined based on what type of branch you merge?
Gary Ewan Park
@gep13
If you follow the processes outlined by GitFlow, then GitVersion respects that, and asserts the correct values, derived from branch names, yes
henrik eriksson
@henrik_GJ_Esson_twitter
Well...we do not fully follow gitFlow. I would say it's gitFlow "style"
But manual selection of the version is the target
Hence the tampering with the commit message
Gary Ewan Park
@gep13
Based on what you have said, I think the best way forward might be to specify what the next version is going to be in the yml file, and from there, GitVersion will use that as the base version, to derive the exact version number from.
henrik eriksson
@henrik_GJ_Esson_twitter
Next version e.g. 5.5.5 and then it will calculate based on what is merged?
if feature branch is merged, then it will increase minor. bugfix will increase patch
Gary Ewan Park
@gep13
A feature branch merge, according to gitflow wouldn't change major, minor or patch version number. Only moving to a release branch or hotfix branch would change the semantic version number. GitVersion follows these basic rules.
henrik eriksson
@henrik_GJ_Esson_twitter
Looking at our installer(advancedInstaller) it does not support semantic versioning for non public releases. Which causes some confusion for internal management of versioning for development versions.
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)