Description
Describe the bug
When using TBD and following configuration in gitversion file
mode: ContinuousDeployment
assembly-informational-format: '{FullSemVer}'
tag-prefix: 'web/'
branches:
develop:
increment: Minor
regex: master
tracks-release-branches: true
prevent-increment-of-merged-branch-version: true
track-merge-target: false
tag: 'dev'
master:
regex: none
hotfix:
regex: ^fix(es)?[/-]web[/-]
source-branches: ['develop']
feature:
regex: ^features?[/-]web[/-]
source-branches: ['develop']
release:
regex: ^releases?[/-]web[/-]
source-branches: ['develop']
increment: Patch
tag: 'qa'
When a new release branch is created (for example release/web/0.19) gitversion works fine when a new tag has been created (for example tag web/0.19.3).
A few days ago a new branch release/web/1.0 was created in order to get ready for launch
Today a new PR with a fix is pushed to release/web/0.19 and the build is named correctly: 0.19.4-qa.4
Then a new tag is created for this patch version: web/0.19.4.
Now gitversion fails giving the right name to the build. It names the build as #1.0.0-tags-production-0-19-4.1+29
Expected Behavior
Build should be named using the new tag
Actual Behavior
Builds are tagged using as base version the newer release branch instead the one where the tag has been created
Possible Fix
Use the version number in tag, if it has been created in the release branch for same major.minor version
Steps to Reproduce
- Create a repo using the previous gitversion file
- Add a couple of commits to
main - Create a release branch
0.1 - Tag the release branch with number
0.1.0 - Create a release branch
1.0 - Add a commit to
main, then cherry pick torelease/0.1 - Tag the release branch with number
0.1.1
Context
Your Environment
Azure DevOps Server 2020
- Version Used: 5.7.0
- Operating System and version (Windows 10, Ubuntu 18.04): Windows / Ubuntu agents