Best to be reviewed with "Hide whitespace".
This PR added release candidate handling and used a switch case to
ensure the correct release type was given.
---------
Co-authored-by: Sebastian "Sebbie" Silbermann <[email protected]>
Co-authored-by: Zack Tanner <[email protected]>
### Why?
When there are no changesets for `next`, the canary release won't be
published even if there are new commits. If this is the case, add an
empty changeset for `next` to let the canary release proceed.
Note that this will result in an empty Changelog and GitHub Release, but
this PR does not cover handling that part.
### Testing Plan
Set env `RELEASE_TYPE=canary` and run `ci:version` locally to see the
result.
---------
Co-authored-by: JJ Kasper <[email protected]>
Co-authored-by: Sebastian "Sebbie" Silbermann <[email protected]>
This PR uses `changesets/action` to handle the canary release. Since the
action creates a Version Packages PR by default, I added a GH Action
that checks if the PR is released from the correct release workflow. It
triple-verifies via the user login (`vercel-release-bot`), PR title
(`Version Packages (canary)`), and a label (`created-by: CI`) to ensure
the opened PR is not trying to spoof.
After the validation, the PR bypasses required checks, is merged into
the canary branch, and proceeds with the rest of the release process.
### Testing Plan
Try running `ci:version` and `ci:publish` locally, and handle the
release type via env `RELEASE_TYPE`.
Confirmed the CI force merge on
https://github.com/devjiwonchoi/lab-releases/pull/13
---------
Co-authored-by: Sebastian "Sebbie" Silbermann <[email protected]>
