Allow pushing git tag after 'publish' step via options.

[levibostian]

Same scenario as this discussion of: if a ‘publish’ step fails because of something such as a network error, it’s no longer possible to simply retry running semantic-release to deploy code again. One must manually delete the pushed git tag (and possibly revert git commits via git plugin) in order to retry pushing the package to the repository.

I understand that because of the ‘verifyConditions’ step of checking credentials early, this scenario should not happen often. However, especially when working on a small team, when this scenario does happen, it becomes a bigger problem. If I am the person who introduces semantic-release to my team, it would be ideal if they could use the tool without having to learn it as well as I do. This scenario has happened multiple times where a deploy will fail on ‘publish’ step for reasons out of our control, a team member retries CI job (as they should be able to, IMO), see that a deploy was not re-tried because git tag already made, then they panic a little not sure what to do. I believe this scenario would be avoided if it was easier to retry running a CI job.

As mentioned in the codebase itself, some workflows require a git tag exists before publishing. Agree, this may be a requirement. However, for other workflows, it is not required and therefore, I believe it should be configurable.

This discussion is to propose an option added to the project to move pushing a git tag until after the ‘publish' and ‘addChannel’ steps is complete and before ‘success’. The default option value is ‘false’ for backwards compatibility. This option can be configured via CLI option or via configuration file.

Today, I use some workarounds to this problem.

1. a plugin that deletes the remote git tag if ‘fail’ step executes. Not ideal for some code bases I work on such as Go and Swift where git tags are how consumers install my code. So if a tag exists, one would think that they can install that code.

2. Write custom publish plugins that push code during ‘prepare’ step instead of during ‘publish’ step. Feels hacky since semantic-release created ‘publish’ step for a reason. This workaround method skips using that step.

I will continue to use workarounds. If maintainers are welcome to a change such as this, I plan to contribute this feature back to the project.

Related issues that I believe could be avoided by this option.

• Cuts a release even if the publish failed? #2027
• [feature request] : push tag on publish phase git#405
• Revert next version Git tag if publishing fails #2381