We would like to use GitVersion for your git repo and the following is our branching strategy.
Master - development branch which will build and deploy every pull request merged. 1.0.0-alpha.x
Release/v1.x.x - release branch which will be deployed end of sprint. 1.0.0-beta.x
Hotfix - branched from master and cherry pick to release branch.
Currently the version on master branch is working fine as 1.0.0-alpha.36 but when i created release branch (release/v1.0.0) it created a version 1.0.0-beta.0 instead 1.0.0-beta.36. What configuration i can set to achieve above.
GitVersion.yml
next-version: 1.0.2
mode: ContinuousDeployment
continuous-delivery-fallback-tag: ''
branches:
master:
mode: ContinuousDeployment
tag: 'alpha'
pull-request:
mode: ContinuousDeployment
tag: 'pr'
increment: None
prevent-increment-of-merged-branch-version: false
tag-number-pattern: '[/-](?<number>\d+)[-/]'
track-merge-target: false
regex: (pull|pull\-requests|pr|[0-9]+)[/-]
tracks-release-branches: false
is-release-branch: false
release:
regex: release?[/]
mode: ContinuousDeployment
tag: 'beta'
is-release-branch: true
ignore:
sha: []
merge-message-formats: {}
Please advise ?
Related
resources:
builds:
- build: Spaceworkz
type: Jenkins
connection: MyJenkinsServer
source: SpaceworkzProj # name of the jenkins source project
trigger: true
Then, I use downloadBuild step.
How can I later in the pipeline get the version number of this build? It will be "latest" but I need the version number.
I can't see anything in doc.
I am finding it difficult to get started with gitversion.
My question here is how to interpret the config file.
I have GitVersion.yml config file which looks like the following.
So now what would be the mode on the second line represent? Is it the default one that would be considered if mode is not specified for a branch?
In the following scenario all of the branches have the mode specified. So what would that mean? For any of the branches(master, release, feature, pull request, hotfix, support and develop) the respective modes specified(for ex ContinuousDeployment is specified for develop) will be considered? Will the mode setting at the branch level override the setting on line 2?
And finally, say I create a new branch urgentfix(not specified in the yaml config file), then ContinuousDelivery mode will be considered because its the default one?
next-version: 6.0.1
mode: ContinuousDelivery
branches:
master:
mode: ContinuousDelivery
tag: ''
increment: Patch
prevent-increment-of-merged-branch-version: true
track-merge-target: false
regex: ^master
tracks-release-branches: false
is-release-branch: false
release:
mode: ContinuousDelivery
tag: beta
increment: Patch
prevent-increment-of-merged-branch-version: true
track-merge-target: false
regex: ^releases?[/-]
tracks-release-branches: false
is-release-branch: true
pre-release-weight: 1000
feature:
mode: ContinuousDelivery
tag: useBranchName
increment: Inherit
prevent-increment-of-merged-branch-version: false
track-merge-target: false
regex: ^features?[/-]
tracks-release-branches: false
is-release-branch: false
pull-request:
mode: ContinuousDelivery
tag: PullRequest
increment: Inherit
prevent-increment-of-merged-branch-version: false
tag-number-pattern: '[/-](?<number>\d+)[-/]'
track-merge-target: false
regex: ^(pull|pull\-requests|pr)[/-]
tracks-release-branches: false
is-release-branch: false
hotfix:
mode: ContinuousDelivery
tag: beta
increment: Patch
prevent-increment-of-merged-branch-version: false
track-merge-target: false
regex: ^hotfix(es)?[/-]
tracks-release-branches: false
is-release-branch: false
support:
mode: ContinuousDelivery
tag: ''
increment: Patch
prevent-increment-of-merged-branch-version: true
track-merge-target: false
regex: ^support[/-]
tracks-release-branches: false
is-release-branch: false
develop:
mode: ContinuousDeployment
tag: unstable
increment: Minor
prevent-increment-of-merged-branch-version: false
track-merge-target: true
regex: ^dev(elop)?(ment)?$
tracks-release-branches: true
is-release-branch: false
ignore:
sha: []
merge-message-formats: {}
To answer your questions:
This is the "global" versioning mode for all branches (unless overridden in a branch configuration under the branches section).
Yes, the modes specified on the individual branch configurations override the global setting on line 2.
In this case (and the documentation isn't 100% clear that this is what happens, but based on my experience, I believe this to be true), since you haven't specified any regexes for your branch configurations, I believe that GitVersion will "fallback" to the defaults. The regex for feature branches is ^features?[/-]. Basically, a branch that optionally starts with feature (singular or plural) followed by a / or - (and not explicitly specified in the regex) followed by anything else. Since urgentfix does not match any of the other branch default regexes (according to GitFlow), urgentfix is considered a feature branch.
For number 3 above, it's unclear to me if the branches section is a free-form section where you can add any branch specification you want (e.g. add an urgentfix: section), or if you must use one of the "pre-defined" ones (which are all based on GitFlow branches).
I suppose you could try creating your own configuration section and see if that works.
If not, you might want to "hijack" one of the other branch configurations you may not be using to achieve what you desire. If you go this route, you may need to override other settings in the configuration, such as source-branches, in order for GitVersion to be able to properly calculate versions. And of course, don't forget to use an appropriate regex so GitFlow knows to use this configuration for urgentfix branches.
HTH.
UPDATE
I just saw in their documentation that you can add your own branch configurations apart from the ones that are well known for GitFlow or GitHubFlow. But the onus is on you to setup the configuration such that GitVersion calculates the version according to your requirements.
I'm pretty new on all AZURE devops.
I did just the minimal install on my VS solution, nuget Gitversiontask in my solution, push to Azure Git pipeline and it worked with the development branch.
I created ( GitFLOW) a feature named dostuff.
Made some changes on classes, then commit & push...
Version feature/my-app 6.1.0-dostuff0001came out ...Nuget pack and push... all fine.
Then did an another commit, pipeline start but at Nuget Push to artifacts ...ERROR 409 (Conflict - The feed already contains 'my-app 6.1.0-dostuff0001).
pipeline
- task: NuGetCommand#2
displayName: 'restore WinFormExtC.sln'
inputs:
restoreSolution: WinFormExtC/ActiveFramework.WinFormExtC.sln
feedsToUse: config
nugetConfigPath: NuGet/NuGet.Config
steps:
- task: VSBuild#1
displayName: 'Build solution WinFormExtC'
inputs:
solution: WinFormExtC/ActiveFramework.WinFormExtC.sln
platform: '$(BuildPlatform)'
configuration: '$(BuildConfiguration)'
steps:
- task: NuGetCommand#2
displayName: 'NuGet pack WinFormExtC'
inputs:
command: pack
packagesToPack: WinFormExtC/Package.nuspec
versioningScheme: byEnvVar
versionEnvVar: GitVersion.NuGetVersion
includeSymbols: true
Your build pipeline references an undefined variable named ‘Parameters.searchPatternPush’. Create or edit the build pipeline for this YAML file, define the variable on the Variables tab. See https://go.microsoft.com/fwlink/?linkid=865972
steps:
- task: NuGetCommand#2
displayName: 'NuGet push'
inputs:
command: push
packagesToPush: '$(Parameters.searchPatternPush)'
publishVstsFeed: '505cb4b9-0633-4d83-b4b6-1e5fc7ad020f'
Question: How can I get the my-app 6.1.0-dostuff0001 increase or change when I queue the pipeline in Azure devops and the build task increment the version of feature branch?
Please remember that I'm new to all this Build, yml, config etc. concept.
Why is my version not incrementing?
GitVersion calculates the semantic version, this will only change once per release. Read more at
version increments
So, to make it incremental we can set and use a config file : GitVersion.yml. Below GitVersion.yml for your reference, it works for me when trigger from master branch.
mode: Mainline
tag-prefix: '[vV]'
commit-message-incrementing: MergeMessageOnly
branches:
feature:
regex: feature?[/-]
source-branches: ['develop']
release:
increment: Minor
regex: release?[/-]
develop:
is-mainline: true
increment: Patch
regex: develop$
master:
regex: master$
More GitVersion related info please reference the following blogs:
Azure DevOps pipelines with YAML and GitVersion
Effective Nuget Package Versioning in Azure DevOps with Git Tags and
GitVersion
So, I am able to deploy a code by using a specific git tag and the build is picking the accurate commit as per that git tag. That is perfectly working, however, the same build is always picking only the latest commit for Jenkinsfile. Is there any way I can make Jenkins pick the Jenkinsfile from a specific commit as well?
Here's my checkout method:
$class: 'GitSCM',
branches: [[name: "refs/tags/${env.tag}"]],
extensions: [[$class: 'CloneOption', noTags: false, shallow: false, depth: 0, reference: '']],
userRemoteConfigs: scm.userRemoteConfigs,
])
We have following branch setup:
master and release/1.0 branches.
master, tagged with 1.0 and producing 1.0.1, 1.0.2 versions.
release/1.0 branch created from master, and master then tagged with 2.0.
The expectation is that both branches produce "stable" versions so there're no prerelease tags.
When running GitVersion on these branches, the release branch produces version 1.0.3 and master branch produces version 2.0.1. So far so good, this is what we expected.
Now one of our colleagues created a new feature branch from the release branch, which they then merge master into afterwards. The feature branch was then merged back into the release branch with a pull request. After the completing the pull request, GitVersion now gives 2.0.X on the release branch, instead of 1.0.X.
To try and fix the issue, we tagged the release branch with 1.0.4. However, with every new commit into release branch, the problem comes back. This forces use to manually tag every commit into release branch to give us our desired version number.
We're using GitVersion 4.0.0-beta0014 in mainline mode.
The config looks like:
mode: mainline
assembly-versioning-scheme: MajorMinorPatch
continuous-delivery-fallback-tag: ''
commit-message-incrementing: Disabled
branches:
master:
tag: ''
feature:
regex: features?[/-]
tag: unstable.{BranchName}
release:
tag: ''
is-mainline: true
bugfix:
regex: bugfix[/-]
tag: unstable.{BranchName}
ignore:
sha: []
Anybody any idea how to get out of this?
Lubos
I think you're looking for the "prevent merge branch increment option" - there's some documentation on it here:
https://gitversion.net/docs/configuration#prevent-increment-of-merged-branch-version
basically you just set it to true in your gitversion.yml like below:
mode: mainline
assembly-versioning-scheme: MajorMinorPatch
continuous-delivery-fallback-tag: ''
commit-message-incrementing: Disabled
branches:
master:
tag: ''
feature:
regex: features?[/-]
tag: unstable.{BranchName}
release:
tag: ''
is-mainline: true
bugfix:
regex: bugfix[/-]
tag: unstable.{BranchName}
ignore:
sha: []
prevent-increment-of-merged-branch-version: true