Following the gitflow branching model on a project, my "development branch" is named dev, my release branches are prefixed with release/, and my "production branch" is master.
Our CI/CD process uses gitversion to apply an alpha-tag (e.g. 0.2.0-alpha.12) to each commit to the dev branch.
When I am ready to make a release, I create a release-branch from a desired commit on the dev branch, push it to the remote, and our CI/CD process uses gitversion to apply a beta-tag (e.g. 0.2.0-beta.1) to the commit.
We currently do not have any GitVersion.yml -- the problem description below is from the default behavior of gitversion.
Problem:
When gitversion is applied to a commit that has an existing tag, it returns the existing commit, not a new one.
E.g. the dev commit from which the release/0.2.0 branch created, is tagged with 0.2.0-alpha.12. When gitversion is run on the newly-created release/0.2.0 branch, the tag it returns is 0.2.0-alpha.12, instead of a new beta-tag.
Desired result:
gitversion can be made to generate a unique tag for an existing commit with an existing tag.
E.g. When gitversion is run on the newly-created release/0.2.0 branch, the tag it returns is 0.2.0-beta.1 regardless that the commit is already tagged with 0.2.0-alpha.12.
Question:
Can gitversion be configured to achieve the desired result, i.e. generate a new beta-tag if run on a release-branch that points to an existing alpha-tagged commit? (I have a decent -- probably not expert -- understanding of git branching and tagging: I understand that in the described scenario, two branches are pointing to the same commit).
As context to this question: our CI/CD process relies on the "SemVer" element of gitversion's output to decide what tag to apply. When newly-pushed release-branches point to existing dev-branch commits (which will have existing alpha-tags), it trips (or desired behavior is not achieved) because the gitversion-generated tag for the release-branch is the existing alpha-tag, instead of the desired new beta-tag.
As illustration:
$ git clone ssh://git@bitbucket.company.com:7999/prj/repo.git
$ git checkout dev
Switched to branch 'dev'
Your branch is up-to-date with 'origin/dev'.
$ git log --oneline -n 1 --decorate
0593fb2 (HEAD -> dev, tag: 0.2.0-alpha.12, origin/dev, release/0.2.0) A useful comment.
$ docker run -u $(id -u ${USER}):$(id -g ${USER}) --rm -v "$(pwd):/repo" artifactory.company.com/gitversion:5.7.1 /repo
{
...
"SemVer": "0.2.0-alpha.12",
...
}
$ git checkout -b release/0.2.0
Switched to a new branch 'release/0.2.0'
$ docker run -u $(id -u ${USER}):$(id -g ${USER}) --rm -v "$(pwd):/repo" artifactory.company.com/gitversion:5.7.1 /repo
{
...
"SemVer": "0.2.0-alpha.12",
...
}
What I've tried:
Typically, I make and commit a change on the newly-created release-branch, in order to generate a new commit that is unique to the release-branch, then run gitversion on this commit. This generates a desired beta-tag. E.g.:
$ touch foo.bar && git add --all && git commit -m "wip" && git log --oneline -n 2 --decorate
[release/0.2.0 98435eb] wip
1 file changed, 0 insertions(+), 0 deletions(-)
create mode 100644 foo.bar
98435eb (HEAD -> release/0.2.0) wip
0593fb2 (tag: 0.2.0-alpha.12, origin/dev, dev) A useful comment.
$ docker run -u $(id -u ${USER}):$(id -g ${USER}) --rm -v "$(pwd):/repo" artifactory.company.com/gitversion:5.7.1 /repo
{
...
"SemVer": "0.2.0-beta.1",
...
}
However, this is often undesirable because the dev-branch commit is perfect as-is, and I've needed to do contrived work.