Release tooling: Release stable releases from latest-release

[JReinhold]

What I did

This PR changes a few things about the release setup, most notably stable releases from next will now be released on latest-release rather than on next-release.

1. The release preparation PR from next will automatically target latest-release if a non-prerelease version bump is chosen.
2. It will then merge latest-release into the branch, resolving any conflicts to the branch's content - to solve any merge conflicts.
3. when the PR has been merged and published, it will be merged from latest-release to main as usual - this shouldn't cause any merge conflicts given that they have already been resolved.
4. when it's on main, we trigger a preminor version bump on next to ensure next is always one minor version ahead of main.

• Closes Release tooling: Bug when making a release after a non-bump release PR has been merged #23886
• renames workflow from "prerelease" to "non-patch-release"
• When a publish workflow starts it will now immediately cancel any preparation workflows to avoid race conditions.

Checklist for Contributors

Testing

The changes in this PR are covered in the following automated tests:

• stories
• unit tests
• integration tests
• end-to-end tests

Manual testing

We need to test this out manually, however it's very hard to do. I think we have to just watch the workflow as it happens live during our next minor release. I'll gladly be responsible for that.

I have tested all the individual pieces locally, the new shell scripts and all.

Documentation

• Add or update documentation reflecting your changes
• If you are deprecating/removing a feature, make sure to update
  MIGRATION.MD

Checklist for Maintainers

• When this PR is ready for testing, make sure to add ci:normal, ci:merged or ci:daily GH label to it to run a specific set of sandboxes. The particular set of sandboxes can be found in code/lib/cli/src/sandbox-templates.ts

• Make sure this PR contains one of the labels below:

  Available labels

  • bug: Internal changes that fixes incorrect behavior.
  • maintenance: User-facing maintenance tasks.
  • dependencies: Upgrading (sometimes downgrading) dependencies.
  • build: Internal-facing build tooling & test updates. Will not show up in release changelog.
  • cleanup: Minor cleanup style change. Will not show up in release changelog.
  • documentation: Documentation only changes. Will not show up in release changelog.
  • feature request: Introducing a new feature.
  • BREAKING CHANGE: Changes that break compatibility in some way with current major version.
  • other: Changes that don't fit in the above categories.

🦋 Canary release

This PR does not have a canary release associated. You can request a canary release of this pull request by mentioning the @storybookjs/core team here.

core team members can create a canary release here or locally with gh workflow run --repo storybookjs/storybook canary-release-pr.yml --field pr=<PR_NUMBER>

[ndelangen]

@JReinhold what's the status of this PR?

[JReinhold]

@ndelangen still needs some minor tweaks before it's mergeable.

[JReinhold]

One thing missing here, is figuring out how to label patch PRs as patched. This works fine when we do an actual patch release, cherry-picking pull requests from next to main, those pull requests will still correctly get the patch:done label. However when we do a stable release from next, we want to label all patch:yes with patch:done, but I'm unsure how to detect when to do that. I can't come up with a good way to determine if a stable release has been done from main or next (and thus which labelling solution to pick).

Some solutions:

1. Treat every minor and major bump as a "release from next" that should label all patch PRs. This creates a tight coupling between version bumps and the branch, and there's nothing but process stopping you from doing a patch release from next, which wouldn't label all patch PRs even though it should.
2. Always label all patch PRs whose commits exists in the git log from HEAD back to the latest stable release. This is the most correct thing to do, it's basically saying "all of these X PRs are part of this new stable release, so they all need patch:done if they have patch:yes." However this could result in traversing thousand of git commits, eg. all the commits between 7.6.0 and 8.0.0, and I can't imagine the GitHub API will let us ask for related PRs to all of those.

@kasperpeulen @shilman any ideas? I would also be okay to punt this, and then just make it a manual step to label all patch PRs when we do major/minor releases from next.

[JReinhold]

@shilman as discussed I made some changes:

1. rename "hotfix release" to "patch release" and "next release" to "non-patch release"
2. Moved two complex workflow steps from inline shell scripts to proper node scripts that are tested. It was quite a bit of code to add, but now it's at least tested and easily runnable locally.

I believe this PR is ready to be merged.

[socket-security]

New dependencies detected. Learn more about Socket for GitHub ↗︎

Packages	Version	New capabilities	Transitives	Size	Publisher
@octokit/request	8.1.2	None	+4	4.81 MB	octokitbot

[JReinhold]

Manually cherry-picked to main.
43825e0