Improve handling of failed release tasks

[danielcompton]

Problem statement:

When doing releases using lein release if the release fails, your project can be left in a partially released state. To fix it you either need to roll back the commits and tags that were made, or roll forward manually, completing the rest of the release by hand. It would be great if there was a way to prevent this from happening.

Ideas:

• Some kind of dry-run mode like Add --dry-run option for deploy and release commands #2229 to allow people to preview what will happen before they release
• Before actually running the release, check that all of the steps can be completed (this is hard to do well because it may depend on remote state like GitHub and Clojars)
• Provide a way to rollback
• If a release fails, show the user which steps succeeded, which one failed, and which ones are left to run.
• Collect the steps remaining to run in a failed release and store them in a temporary file like .lein-release-tasks so they can be rerun on a second attempt.

[technomancy]

When doing releases using lein release if the release fails, your project can be left in a partially released state. To fix it you either need to roll back the commits and tags that were made, or roll forward manually, completing the rest of the release by hand. It would be great if there was a way to prevent this from happening.

Atomic releases would be really nice to have, and we've discussed it before, but the problem is it depends on having atomic deploys. Our hands are somewhat tied by the existing semantics of Aether. We could create a new clojars-specific wagon which supported wrapping up all the files and signatures into a single atomic unit that gets committed all at once, but last I looked there was no way to do this in the existing ecosystem without doing a little embrace-and-extend action. I'd be open to a proposal for this, but it's a lot of work with a lot of subtle gotchas. I'm a little more skeptical of the idea of rollbacks considering you can set release-tasks to any arbitrary task, so it would require a more general-purpose notion of rolling back that could apply universally. But if we had atomic deploys plus a "look before you leap" command for git tagging, I think that'd get you 99% of the way there.

* If a release fails, show the user which steps succeeded, which one failed, and which ones are left to run.

This is a great idea with no downsides as far as I'm concerned. I'd accept a patch for this in a heartbeat.

* Collect the steps remaining to run in a failed release and store them in a temporary file like .lein-release-tasks so they can be rerun on a second attempt.

Likewise for this, assuming it built on the previous step.