0

Does GitversionTask require manually tagging commits on the master branch? Would this typically be done on the build server that completes the pull request?

When we have master on 1.1.4 and then merge a release branch 1.2.0-FeatureA, I'd expect master to then be on 1.2.0. However, without a manual tag, according to gitversion it is on 1.1.5. Presumably, gitversion cannot distinguish if this commit came from a hotfix pull request or a release pull request. I'm not sure if I understand the philosophy of gitversion.

Ideally, all semantic versioning should be done by GitversionTask. And if necessary, we would have the possibility to bump the major. Every commit on the master branch should have unique SemVer.

raw
  • 99
  • 1
  • 5
  • Check [this ticket](https://stackoverflow.com/a/47090361/13464420). You need to put the gitversion task in the CI build instead of PR validation build. –  Aug 20 '20 at 09:27

1 Answers1

0

When I've used GitVersion on a build pipeline to manage the semantic version, I've used an extension like Git Tag to automate the tagging after it has calculated the semantic version.

Matt
  • 3,658
  • 3
  • 14
  • 27
  • Well, from which pipeline? When using the build pipeline, that would already be too late. This pipeline is triggered by a new commit on the master. The pipeline has no information from which branch it came frome (release xy), as the release or hotfix branches are gone. https://stackoverflow.com/questions/60540841/how-to-automatically-git-tag-a-after-a-pull-request-has-completed-on-azure-de – raw Aug 06 '20 at 15:02