Skip to content

Add instructions for failure #6

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Draft
mpkorstanje wants to merge 1 commit into
base: main
Choose a base branch
from
Draft

Add instructions for failure #6

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 5 additions & 1 deletion RELEASING.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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.

@mpkorstanje mpkorstanje May 14, 2022 •
edited
Loading

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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.

@mattwynne mattwynne May 16, 2022 •
edited
Loading

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.Z release tag is pointing at the correct commit.

@aurelien-reeves aurelien-reeves May 17, 2022 •
edited
Loading

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

@mattwynne mattwynne May 17, 2022

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

@aurelien-reeves aurelien-reeves May 17, 2022 •
edited
Loading

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

@mattwynne mattwynne May 17, 2022

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

@aurelien-reeves aurelien-reeves May 17, 2022 •
edited
Loading

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why would you delete the release branch first?

@mattwynne mattwynne May 18, 2022

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess I'm getting confused between your workflow and mine. I think yours sounds better!

@aurelien-reeves aurelien-reeves May 18, 2022 •
edited
Loading

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What I have in mind is that:

  • At first, you have your main branch that you want to deploy, so:

    • git push to push main to origin
    • git push origin main:release/vX.Y.Z to 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 push to push main to origin
    • git push origin main:release/vX.Y.Z to 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



3. Announce the release
* in the `#newsletter` Slack channel
* on the `@cucumberbdd` Twitter account
* write a blog post
Expand Down