Release rollbacks #1953
-
Hi! I have a general question: can Auto handle failed release and rollback changes from the steps before failure? And I have a concrete situation: I'm trying to use Auto in a Scala (sbt) project. Here is my plugins:
- git-tag
- released
- - exec
- publish: "sbt publish"
shipit:
noChangelog: true On CI I run At first, I misconfigured sbt and publishing step failed. But it could fail for any other reason (server error, etc.). Unfortunately, the git tagging step happens before So after the failure, I have a tag on the remote, but no release and no published artifacts. If I fix the issue or just rerun, it will bump the version again and skip all changes from the failed release. Is it possible to configure git-tag/exec plugins to do it in this order:
So that if the process fails on step 3 (publishing artifacts), there are no changes on the remote, and it's safe to rerun or push another change (e.g. a fix) and have everything released as if there was no failed release. Another approach to this would be to have a rollback step and delete the pushed tag if the release failed (thus my general question in the beginning). I think it's more complicated and the right order of steps would cover most situations (IMO artifacts publishing is the most "fragile" step). |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments 4 replies
-
As always, after writing the question I sort of realized the answer 😅 I tried changing the order of plugins in the config: plugins:
- - exec
- publish: "sbt publish"
- git-tag
... And now it runs git-tag/version, exec/publish, git-tag/publish, etc. And I tested that if the exec/publish fails, the tag is not published. While my immediate case is solved, I still have a couple of questions: Is the order of plugins an undocumented feature? Are there any better ways to achieve the result? + the general question about rollbacks 🙂 |
Beta Was this translation helpful? Give feedback.
-
Not an answer, but continuing the discussion re:
I've seen this happen too, when the auto release is necessarily a completely separate step in the workflow before the actual build step runs and subsequently fails. @hipstersmoothie I would expect that if nothing source code related changes, then when re-running the workflow the auto release step should do nothing at all - certainly not bump the version and pile on yet another tag and release - leaving just the build step to do its thing; i.e. auto release should be idempotent. This is especially important when the build step might run into unrelated transient errors. |
Beta Was this translation helpful? Give feedback.
As always, after writing the question I sort of realized the answer 😅 I tried changing the order of plugins in the config:
And now it runs git-tag/version, exec/publish, git-tag/publish, etc. And I tested that if the exec/publish fails, the tag is not published.
I also noticed that there is a
afterVersion
hook that I could use in exec, but I think it's not the right place for publishing artifacts.While my immediate case is solved, I still have a couple of questions:
Is the order of plugins an undocumented feature? Are there any better ways to achieve the result? + the general question about rollbacks 🙂