Add instructions for failure #6
Conversation
| @@ -69,7 +69,11 @@ polyglot-release <new version> | |||
| ``` | |||
| 1. Wait until the `release-*` workflows in GitHub Actions have passed | |||
| 1. Rerun individual workflows if they fail | |||
| 1. Announce the release | |||
|
|
|||
| If there's something wrong with the release workflows themselves, you can make changes and git push --force to the release branch to re-run the workflow. Don't forget to merge any changes back to main afterwards. | |||
There was a problem hiding this comment.
@mattwynne you suggested #3 (comment). Though I'm wondering, if we force push to the release branch, what happens to the git tag? Shouldn't that also be forced pushed?
Sounds like a recipe for problems.
There was a problem hiding this comment.
I'm not sure. It's possible that the github release action will move the tag (it certainly adds a tag if there isn't one already) but we'd need to try it to establish that for sure.
This isn't something that happens very often, and I'd expect that the person doing it would be able to figure it out. I just thought it was nice to leave them a clue!
If we want to be clear we could add:
Don't forget to merge any changes back to main afterwards, and make sure the
vX.Y.Zrelease tag is pointing at the correct commit.
There was a problem hiding this comment.
Well, what's the point of a forced push here?
If there is something wrong which does not involve a new commit, the workflow should be re-triggered manually using the github UI rather than forcing a push. That would be less error-prone
And if a commit is involved: push to main, then push to the release branch, as usual, that should do the trick
And if any doubt, call for help on slack
There was a problem hiding this comment.
I'm talking specifically about when you need to fix something in one of the release workflow yaml files and re-run it. I've been in that loop a few times, especially when setting up a new repo.
I can imagine we'll get regressions, especially in repos that haven't been released for a while.
There was a problem hiding this comment.
I've been there.
Pushing on main, then on the release branch, without forcing the push, is working fine. There is no need to force push here
There was a problem hiding this comment.
So just delete the existing release branch first? Yes, that sounds good.
Could you express your workflow in words?
Maybe this deserves its own little section in the doc.
There was a problem hiding this comment.
Why would you delete the release branch first?
There was a problem hiding this comment.
I guess I'm getting confused between your workflow and mine. I think yours sounds better!
There was a problem hiding this comment.
What I have in mind is that:
-
At first, you have your main branch that you want to deploy, so:
git pushto push main to origingit push origin main:release/vX.Y.Zto push the exact same head to a release branch
-
Something went wrong, you fix it, you commit to main, and then your do the exact same thing:
git pushto push main to origingit push origin main:release/vX.Y.Zto update the release branch accordingly
No need to force push becaus the release branch is actually an exact copy of main. If it is possible to push to main, it is possible to push to the release branch without forcing it or deleting it. The release workflow will be triggered the exact same way. The only thing that still has to be fixed is the tag, but that is not even mandatory in the case where you fix nothing else than a workflow: the released package itself should not be impacted
🤔 What's changed?
What to do in case of failure?