Background
When an automatic workflow with the commitizen-action is set to run on pushes to a remote branch, whenever two separate pushes are done in short succession (less time than it takes for the workflow triggered by the earlier push to finish) the bumps will not complete successfully and a git tag will be pushed in a detached state.
Cause
The workflow that was triggered by the early most push will check the repository out on commit that will then be outdated after the second push happens. The cz bump command then gets executed on an outdated commit, the rebase triggered by the git pull command will move the "bump commit" to be the most recent commit of the branch, however since a git rebase effectively creates new commits the git tag created by cz bump will be left on the old outdated bump commit in a "detached state", at the end since the git push ... --tags command doesn't do any checks as regarding to the state of the pushed tags the tag will be pushed in the "detached state" (not part of the (or any) branch) to the remote repository.
The latter workflow will than fail, if trying to increment to the same version, to push its tags to remote as that tag is already present there (in the "detached state").
Possible solution
Background
When an automatic workflow with the
commitizen-actionis set to run on pushes to a remote branch, whenever two separate pushes are done in short succession (less time than it takes for the workflow triggered by the earlier push to finish) the bumps will not complete successfully and a git tag will be pushed in a detached state.Cause
The workflow that was triggered by the early most push will check the repository out on commit that will then be outdated after the second push happens. The
cz bumpcommand then gets executed on an outdated commit, the rebase triggered by thegit pullcommand will move the "bump commit" to be the most recent commit of the branch, however since a git rebase effectively creates new commits the git tag created bycz bumpwill be left on the old outdated bump commit in a "detached state", at the end since thegit push ... --tagscommand doesn't do any checks as regarding to the state of the pushed tags the tag will be pushed in the "detached state" (not part of the (or any) branch) to the remote repository.The latter workflow will than fail, if trying to increment to the same version, to push its tags to remote as that tag is already present there (in the "detached state").
Possible solution
commitizendocumentation for GitLab CI: https://un5kw2gkrpppctvjyvwcygk4bugrg3g9vcx0.julianrbryant.com/commitizen/tutorials/gitlab_ci/#stages-and-jobs)