Gitversion: Unable to remove -ci from master builds

[MrHinsh]

Guys,

I don't want to have the "-ci0015" appended to my MASTER builds when using ContinuousDeployment. How do I turn that off?

assembly-versioning-scheme: None
mode: ContinuousDeployment
next-version: 0.4.8
branches:
  master:
    mode: ContinuousDeployment
    tag: ''
ignore:
  sha: []

I have tried the above!

[gep13]

@MrHinsh what version of GitVersion are you using? When you say you have tried the above, does that mean you have just now changed the yml file? If so, have you cleared the gitversion_cache folder, in order to ensure that you are not seeing a cached version of the asserted version number being returned?

[MrHinsh]

I am building with 3.6.2 on the hosted service of VSTS, so its a fresh build server each time.

The value of "GITVERSION_NuGetVersionV2" includes "-ci.16" and on the MASTER branch I would want it to not include a pre-release tag... my CI has already passed the benchmarks and tests for release and I want to ship it.

How can I tell GitVersion that MASTER branch builds should never include a pre-release tag?

[gep13]

@JakeGinnivan you around?

[pascalberger]

@MrHinsh How are you fetching the repository? By default VSTS doesn't fetch all tags, which can lead to this behavior.

See the known limitations section in the documtation:

You need to make sure that all tags are fetched for the Git repository, otherwise you may end with wrong versions (e.g. FullSemVer like 1.2.0+5 instead of 1.2.0 for tagged releases) Just checking the Clean Repository check box in the build definition settings might not be enough since this will run a git clean -fdx/reset --hard without fetching all tags later. You can force deletion of the whole folder and a re-clone containing all tags by settings the variable Build.Clean to all. This will take more time during build but makes sure that all tags are fetched. In the future it is planned to allow using git.exe instead of current libgit2sharp for syncing the repos which might allow other possibilities to solve this issue. For details see this GitHub issue.

[qetza]

@MrHinsh add the following configuration continuous-delivery-fallback-tag: ''

assembly-versioning-scheme: None
mode: ContinuousDeployment
continuous-delivery-fallback-tag: ''
next-version: 0.4.8
branches:
  master:
    mode: ContinuousDeployment
    tag: ''
ignore:
  sha: []

Even though the variable is named continuous-delivery it is used on continuous deployment...

[JakeGinnivan]

@qetza doh, that is annoying. We should fix that.

@MrHinsh when continuous delivery was implemented we used this thinking: http://gitversion.readthedocs.io/en/latest/more-info/incrementing-per-commit. We didn't want to assume each commit was a bug fix (and each merged PR would skip a bunch of patch versions) so the only logical place to put it is in the pre-release tag. This ends up causing all sorts of issues, especially if you are publishing NuGet packages because pre-release is viral.

In v4 we are introducing a new mode called mainline, each merged branch or direct commit to master is treated as a release. So when you merge a PR you will only bump a single patch release, even if the branch contained 10 commits and is probably what you want. We still have some issues to work out with mainline development mode but hoping to get it out in the next week or two.

For now, you could build your own version number. i.e $(Major).$(Minor).$(Patch).$(PreReleaseNumber) to get a 4 part version number. Not the greatest solution.

Another way is to actually use Continuous Delivery mode, then I am assuming you are using VSTS release management. Your release number should contain the $(rr.rev) so you can deploy the same version again. Then when you promote to a particular environment add a task which goes back and tags your VCS which can bump the patch version number.

[JakeGinnivan]

Removing VSTS tag as this is actually not a VSTS issue.

[JakeGinnivan]

There are a few ways we could change the behavior. Unsure which is the best, each has it's downsides

1. Move to a 4 part version

+ No pre-release tag
- No longer follows SemVer

Could also expose a FourPartNuGetVersion or something also to make it easy to pick this one up now.

2. Promote number of commits since base to patch

? What happens to patch?
+ No pre-release tag
- Skips multiple patch versions per release, also likely would not be able to just bump minor/major without patch being bumped as well because patch is counting commits now

Would love thoughts on which direction we should go.

[MrHinsh]

@JakeGinnivan Having the option of [1] would be awesome, even if it is not SemVer... I would be interested in telemetery on its usage.

I thought about [2] and rejected it for the reasons that you specified.

Unfortuantly PreReleaseNumber is blank :(

[ { "Name": "GITVERSION_LEGACYSEMVERPADDED", "Value": "0.6.0" }, { "Name": "GITVERSION_COMMITDATE", "Value": "2016-08-11" }, { "Name": "GITVERSION_PRERELEASETAG", "Value": ".18" }, { "Name": "GITVERSION_PRERELEASENUMBER", "Value": "" }, { "Name": "GITVERSION_INFORMATIONALVERSION", "Value": "0.6.0+Branch.master.Sha.406e7fac606ef3ee21d71795ab68fea375648878" }, { "Name": "GITVERSION_NUGETVERSIONV2", "Value": "0.6.0" }, { "Name": "GITVERSION_MAJOR", "Value": "0" }, { "Name": "GITVERSION_SHA", "Value": "406e7fac606ef3ee21d71795ab68fea375648878" }, { "Name": "GITVERSION_PATCH", "Value": "0" }, { "Name": "GITVERSION_PRERELEASELABEL", "Value": "" }, { "Name": "GITVERSION_LEGACYSEMVER", "Value": "0.6.0" }, { "Name": "GITVERSION_NUGETVERSION", "Value": "0.6.0" }, { "Name": "GITVERSION_BUILDMETADATA", "Value": "" }, { "Name": "GITVERSION_FULLBUILDMETADATA", "Value": "Branch.master.Sha.406e7fac606ef3ee21d71795ab68fea375648878" }, { "Name": "GITVERSION_MAJORMINORPATCH", "Value": "0.6.0" }, { "Name": "GITVERSION_COMMITSSINCEVERSIONSOURCEPADDED", "Value": "0018" }, { "Name": "GITVERSION_SEMVER", "Value": "0.6.0" }, { "Name": "GITVERSION_FULLSEMVER", "Value": "0.6.0" }, { "Name": "GITVERSION_PRERELEASETAGWITHDASH", "Value": "" }, { "Name": "GITVERSION_BUILDMETADATAPADDED", "Value": "" }, { "Name": "GITVERSION_COMMITSSINCEVERSIONSOURCE", "Value": "18" }, { "Name": "GITVERSION_ASSEMBLYSEMVER", "Value": "" }, { "Name": "GITVERSION_BRANCHNAME", "Value": "master" }, { "Name": "GITVERSION_MINOR", "Value": "6" } ]

[qetza]

@JakeGinnivan i think number 1 could be done by exposing a new variable and could be extremely usefull even without nuget. For example when dealing with MSI installer, file version with 4 parts are used to know if a file need to be changed, currently i'm recreating this 4 part version in build scripts using CommitsSinceVersionSource.

@MrHinsh seems like a bug because, it should be 18 like GITVERSION_COMMITSSINCEVERSIONSOURCE. I'll look into this.

[JakeGinnivan]

We should actually try and do some opt in telemetry, would be super useful. Though exposing a new variable would not give us telemetry on their use and I want to avoid new options, it's already pretty confusing.

I am working on http://gitversion.readthedocs.io/en/latest/reference/mainline-development which at the moment seems like it will be a great compromise. Though there is still bugs in v4 so not deploying to VSTS because you cannot choose the version you are running. You would have to switch to command line to test or put GitVersion into your build scripts (Cakebuild.net has great support).

[MrHinsh]

OK, so my .yml file now looks like:

assembly-versioning-scheme: None
mode: ContinuousDeployment
continuous-delivery-fallback-tag: ''
next-version: 0.4.8
branches:
  master:
    mode: ContinuousDeployment
    tag: ''
ignore:
  sha: []

However now I can only increment major with +semver:major and nothing happens when I do +semver:minor or +semver:patch...

I would have expected both minor and patch to increment as normal...

[JakeGinnivan]

+semver: messages are a hint rather than a command.

For instance if I have +semver: minor in a commit, then +semver: major then +semver:minor in a single PR then GitVersion will simply bump major. Both continuous delivery and continuous deployment will calculate this since the last tag. So without tagging commits with the built version this won't work for you :(

When v4 drops Mainline mode will sort your issue though. It treats each merged branch and direct commits against master as a release, then aggregate each increment.

You can give it a try by using the command line outside of VSTS, or try uploading the vsix from https://github.com/GitTools/GitVersion/releases/tag/v4.0.0-beta.5, but unsure you can upload beta releases (we don't push beta releases into VSTS as it will automatically upgrade everyone before we are entirely happy).

[MrHinsh]

Even with a single +semver:minor in a commit to master there is no bump in version at all when using the .yml above.

Do you have a guestimate of when you plan on shipping 4.0?

[ryudice]

Was this addressed at some point?

[martinfletcher]

Any update on this?

[JakeGinnivan]

Continuous deployment mode will always add this, the docs link to a blog post which explains the reason quite well.

We really need to release v4 stable soon, but if you grab the beta, mainline mode probably does exactly what you want.

[JakeGinnivan]

See https://gitversion.readthedocs.io/en/latest/reference/mainline-development/ for info on mainline mode

[BenjaminAbt]

any roadmap when will this be available via stable (and VSTS GitVersion Task) ?

Okay, I created a custom VSTS task to use .beta12

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. After 30 days from now, it will be closed if no further activity occurs. Thank you for your contributions.

[kinguru]

Just merged hotfix/6.17.1 to the master, and got 6.17.0-ci.204 from master build. Is it ok?