When pushing atomically, if the commit is rejected (let's say a PR has been merged concurrently, we got a non-fast-forward error), then the tag would be rejected as well (with a atomic push failed).
In that situation, with the current implementation, a fallback non-atomic push is attempted as a retry (because the error message DOES contain the word "atomic").
We ends up with an orphan tag being pushed, preventing further release process to be achieved with success, until we manually delete the tag.
I don't understand why the condition on fallback non-atomic attempt is implemented like that.
Thanks in advance for your help & clarification on how we should use that correctly.
Hello & thank you for this plugin,
As of now, when the atomic git-push failed for some reason, if the error contains the word "atomic", then a fallback to non-atomic push is attempted.
See: https://github.com/jscutlery/semver/blob/0ff884d9797d5c2d69838c3782bbc03b0cca0c97/packages/semver/src/executors/version/utils/git.ts#L96-L118
When pushing atomically, if the commit is rejected (let's say a PR has been merged concurrently, we got a
non-fast-forward error), then the tag would be rejected as well (with aatomic push failed).In that situation, with the current implementation, a fallback non-atomic push is attempted as a retry (because the error message DOES contain the word "atomic").
We ends up with an orphan tag being pushed, preventing further release process to be achieved with success, until we manually delete the tag.
I don't understand why the condition on fallback non-atomic attempt is implemented like that.
Thanks in advance for your help & clarification on how we should use that correctly.