I am using GitVersion in an Azure DevOps pipeline to automate deployments, however I'm struggling to get the automatic versioning to work as I want.
The branch structure is like this:
master- this is the main branch and where prod releases are done fromdev- this is the current development version sitshotfix*- these are short-lived branches from master which are for hotfixes, usually in the form "hotfix-bug#99999"**- any development is done in a branch offdevand merged back intodev, these don't have any specific naming convention
What I want to happen is:
- Pull requests from any branch into
devupdates the pre-release number (e.g.1.0.0goes to1.0.0-something) - Pull requests from dev into master updates Minor (e.g.
1.0.0goes to1.1.0) - Pull requests from any hotfix branch into master updates Patch (e.g.
1.0.0goes to1.0.1)
I want to avoid having to use git Tags to control the versioning because it means every pipeline has to run twice to get the correct version in the build.
Current workflow goes:
- Pull request is completed in DevOps
- This triggers pipeline
- Locally fetch changes from pull request
- Add tag to latest commit (e.g.
1.1.0) - Push tags
- Re-run pipeline (now GitVersion takes desired version number)
My current GitVersion.yml file is below:
assembly-versioning-scheme: MajorMinorPatch
assembly-file-versioning-scheme: MajorMinorPatch
mode: ContinuousDelivery
tag-prefix: '[vV]'
continuous-delivery-fallback-tag: ci
major-version-bump-message: '\+semver:\s?(breaking|major)'
minor-version-bump-message: '\+semver:\s?(feature|minor)'
patch-version-bump-message: '\+semver:\s?(fix|patch)'
no-bump-message: '\+semver:\s?(none|skip)'
legacy-semver-padding: 4
build-metadata-padding: 4
commits-since-version-source-padding: 4
tag-pre-release-weight: 60000
commit-message-incrementing: Enabled
branches:
develop:
mode: ContinuousDeployment
tag: alpha
increment: Minor
prevent-increment-of-merged-branch-version: false
track-merge-target: true
regex: ^dev(elop)?(ment)?$
source-branches: []
tracks-release-branches: true
is-release-branch: false
is-mainline: false
pre-release-weight: 0
main:
mode: ContinuousDelivery
tag: ''
increment: Patch
prevent-increment-of-merged-branch-version: true
track-merge-target: false
regex: ^master$|^main$
source-branches:
- develop
- release
tracks-release-branches: false
is-release-branch: false
is-mainline: true
pre-release-weight: 55000
release:
mode: ContinuousDelivery
tag: beta
increment: None
prevent-increment-of-merged-branch-version: true
track-merge-target: false
regex: ^releases?[/-]
source-branches:
- develop
- main
- support
- release
tracks-release-branches: false
is-release-branch: true
is-mainline: false
pre-release-weight: 30000
feature:
mode: ContinuousDelivery
tag: '{BranchName}'
increment: Inherit
regex: ^features?[/-]
source-branches:
- develop
- main
- release
- feature
- support
- hotfix
pre-release-weight: 30000
hotfix:
mode: ContinuousDelivery
tag: beta
increment: Patch
prevent-increment-of-merged-branch-version: false
track-merge-target: false
regex: ^hotfix(es)?[/-]
source-branches:
- release
- main
- support
- hotfix
tracks-release-branches: false
is-release-branch: false
is-mainline: false
pre-release-weight: 30000
ignore:
sha: []
increment: Inherit
commit-date-format: yyyy-MM-dd
merge-message-formats: {}
update-build-number: true
This is the config I'm now using which does I need/works with the workflow described in the question: