Commit Graph

6 Commits

Author SHA1 Message Date
Jiwon Choi c8f3be7e89 Clean up new release process (#85458) 2025-10-29 00:17:24 +01:00
Jiwon Choi e5f2e0f9c1 [release-new] fix: release pr commit contains (#number) at last (#79611)
When the "Version Packages" PR is merged, the created commit is the
format of "Version Packages (#number)". Therefore, the
check-is-release.js script won't match the current regex. Also, I
modified the workflows that use the `check-is-release.js` to consider
the new release as a release workflow as well.
2025-05-26 14:02:49 +02:00
Jiwon Choi d8be11a62b [release] use changesets/action for release-candidate (#79039)
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 <sebastian.silbermann@vercel.com>
Co-authored-by: Zack Tanner <1939140+ztanner@users.noreply.github.com>
2025-05-23 15:34:02 +02:00
Jiwon Choi 85c6b3a03d [release] use changesets/action for canary release (#79038)
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 <sebastian.silbermann@vercel.com>
2025-05-19 19:48:41 +02:00
Jiwon Choi 5333dda84f [release] add new ci to use changesets/action for stable release (#79037)
This PR added `.github/workflows/trigger_release_new.yml`, which is a port of `.github/workflows/trigger_release.yml` and modified [publishRelease](https://github.com/vercel/next.js/blob/8223eb86925e575cd641b55626b4bbc4a4d788c6/.github/workflows/build_and_deploy.yml#L529) to use the `changesets/action` to publish to NPM and GitHub Release.

This workflow uses [changesets/action](https://github.com/changesets/action) to publish NPM and GitHub Release. The main difference is that the GitHub Release will be published per package.

### Testing Plan

Try running `ci:version` and `ci:publish` locally.
2025-05-19 18:43:16 +02:00
JJ Kasper 6b863fe294 Apply publish step optimizations (#43620)
Follow-up to https://github.com/vercel/next.js/pull/32337 this removes
the un-necessary step where we fetch all of the tags which requires
pulling a lot of un-necessary git history inflating cache size and
publish times.

The only reason these tags were needing to be fetched is due to an issue
in how the `actions/checkout` step works
(https://github.com/actions/checkout/issues/882).

This reduces the publish times by at least 4 minutes by removing the
tags fetching step
https://github.com/vercel/next.js/actions/runs/3598569786/jobs/6061449995#step:16:14

As a further optimization this adds concurrency to the `npm publish`
calls themselves to hopefully reduce time spent there as well.
2022-12-01 21:48:51 -08:00