Release tooling: Support canary releases

[JReinhold]

What I did

This PR adds support for canary releases.

• Anyone with admin privileges can manually trigger a workflow run and specifying the PR number to create a release for.
• contributors and maintainers are instructed to ask the core team if they would like a canary release of their PR
• the workflow must always be triggered from the default branch next, and not the actual branch you want the release for. This is for security reasons.
• If a canary release succeeds, the PR description will be updated with the release information (see at the bottom of this PR body)
• If a release fails, a comment will be made tagging the triggering actor, see Core: Fix useStoryPrepared hook failing with undefined data #22631 (comment)
• The canary will have the following version format: <CURRENT_VERSION>-canary-<PR_NUMBER>-<TIMESTAMP>-<COMMIT_SHA>.0, eg. 7.1.1-pr-23508-1689802571-5ec8c1c3.0. It's a bit verbose.
  • The current version has no meaning, it just softly indicates which version the PR is based on. eg. this PR is based on 7.1.0, so it will get released as a canary version of 7.1.1.
  • The timestamp ensures that any subsequent releases are always considered newer.
  • The commit hash is not strictly necessary, but it's a good way to indicate which exact code has been released.

How to test

You can test this out by reading the documentation in this PR, and then using this branch as a ref when running the workflow, instead of next. So in the UI you'd choose canary-release-workflow instead of next, and with the CLI it would be:

gh workflow run --repo storybookjs/storybook --ref canary-release-workflow canary-release-pr.yml --field pr=<PR_NUMBER>

To test the updating of the PR description you need to add the following to the bottom of your description before triggering the workflow:

### 🦋 Canary release

<!-- CANARY_RELEASE_SECTION -->
This pull request has been released as version [`7.1.1-canary-23508-1690059187-2dbf6e38.0`](https://npmjs.com/package/@storybook/cli/v/7.1.1-canary-23508-1690059187-2dbf6e38.0). Install it by pinning all your Storybook dependencies to that version.
<details>
<summary>More information</summary>

| | |
| --- | --- |
| **Published version** | [`7.1.1-canary-23508-1690059187-2dbf6e38.0`](https://npmjs.com/package/@storybook/cli/v/7.1.1-canary-23508-1690059187-2dbf6e38.0) |
| **Triggered by** | @JReinhold |
| **Repository** | [storybookjs/storybook](https://github.com/storybookjs/storybook) |
| **Branch** | [`canary-release-workflow`](https://github.com/storybookjs/storybook/tree/canary-release-workflow) |
| **Commit** | [`2dbf6e38`](https://github.com/storybookjs/storybook/commit/2dbf6e38cca59573408cf9d58d245a3125c980d7) |
| **Datetime** | Sat Jul 22 20:53:07 UTC 2023 (`1690059187`) |
| **Workflow run** | [5632680651](https://github.com/storybookjs/storybook/actions/runs/5632680651) |

To request a new release of this pull request, mention the `@storybookjs/core` team.

_core team members can create a new canary release [here](https://github.com/storybookjs/storybook/actions/workflows/canary-release-pr.yml) or locally with `gh workflow run --repo storybookjs/storybook canary-release-pr.yml --field pr=23508`_
</details>
<!-- CANARY_RELEASE_SECTION -->

[ndelangen]

@JReinhold this seems a bit annoying to remember & have to do. Is this something you could append if not detected?

[shilman]

@JReinhold Doesn't this mean that each package is going to have a million dist tags? Can we not do that please?

[JReinhold]

@JReinhold this seems a bit annoying to remember & have to do. Is this something you could append if not detected?

@ndelangen this is only something you have to manually add now because this PR isn't merged. This PR also changes the default PR template to include this section, so any future PRs will have this section per default. Any existing PRs will not, but I'm thinking that's okay? If you think it's common to create PRs that doesn't use the template, then I'm fine with adding in additional measures to handle it.

@JReinhold Doesn't this mean that each package is going to have a million dist tags? Can we not do that please?

@shilman actually it's not possible to publish a package without tag, it will default to latest of nothing is provided. We can publish all canaries to the same canary tag, but we'd have to be explicit to users about never using it, because it wouldn't make sense. I'm okay with it, this looks like this is what React and Auto does.

[shilman]

We can publish all canaries to the same canary tag, but we'd have to be explicit to users about never using it, because it wouldn't make sense. I'm okay with it, this looks like this is what React and Auto does.

Yes please!

[JReinhold]

@shilman I've made the changes so all releases use the same canary tag.

We can remove the two dist tags I've created with this work manually: yarn npm tag remove @storybook/cli pr-23508, or maybe with something smarter:

yarn workspaces foreach --no-private --parallel exec "cat package.json | jq .name" | xargs -L1 yarn npm tag remove $@ pr-23508

I can do it or you can, I'll need the npm token though.

[shilman]

Thanks for fixing the dist tag!

[yannbf]

This has been released, can you replace and test it out?

[JReinhold]

It's been merged, but not released. :( I think they want to write some tests first, before releasing a new version. I'm keeping an eye on it.

[kylegach]

Docs look good!