Do not leave the local repository in an inconsistent state when publishing fails

[unflxw]

When publishing a package with mono publish, Mono will shell out to a language-specific package publishing command. If that command fails, then the local git repository will be left in an inconsistent state. There will be a commit in the current branch in your local repository describing the release that didn't happen, and a tag, named after the version that was never published, pointing to that commit.

To re-attempt the release, the following manual steps are necessary before running mono publish again:

• git reset --hard HEAD^ to remove the "Publish package" commit
• git tag -d <tag> to remove the tag pointing to that commit

If the "Publish package" commit is not manually removed, Mono will warn that there are no changes and abort the publishing process at the beginning. However, if the tag is not manually removed, Mono will go ahead with the release, resulting in a failure before reaching the language-specific publishing command, when attempting to create a tag that already exists.

There are many ways this could be addressed at different levels, theoretically at least:

• Warn and abort early if the tag for the version about to be released already exists: Check if tags exist before publishing #60
  • Alternatively, one of the following:
    • Always override the tag for the version about to be released (git tag -f)
    • Ask the user whether to override the tag for the version about to be released if it exists
• Do not create a commit and a tag for the release until the language-specific publishing command has succeeded
  • If the above is not possible, as we need to create the commit for the release to include the changelog:
    • Restore the repository to its previous state if the language-specific publishing command fails: Rollback when publishing fails #61

[tombruijn]

I like that we make a commit before publishing to the package managers. I did that on purpose so we can be very sure that the current state is the same as the published package. Previously it published first and then committed, which could result in some different state (due to Git hooks).

As you say, we can have better handling for when things go wrong.

• We can add a check for the tag existence.
• We can revert the commit and tag on publish failure.