Description
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
- Don't rebase before pushing the bump commit and push the created tag separately, only if the commit was pushed correctly - in the case of the race condition described above the earlier workflow will fail, however the subsequent workflow runs will run correctly and no tags in the detached state will be pushed to the remote. (This is also similar to the example provided in the
commitizendocumentation for GitLab CI: https://commitizen-tools.github.io/commitizen/tutorials/gitlab_ci/#stages-and-jobs)