A `pnpm install` installs native bindings for Next.js by default. This
makes sense for local development where half of the team doesn't work on
native code and just needs the most recent bindings. However, CI almost
exclusively wants to test with bindings that are built from the current
commit. The rest doesn't need native bindings at all.
The only exception is `test_examples` which is likely not functional.
Though we still support it by allowing to opt-into automatically
installing native bindings in CI.
## test plan
- [x] fetch test timings still skips:
https://github.com/vercel/next.js/actions/runs/28087707205/job/83157705446?pr=95114#step:7:228
Add a `preview` release type so `@preview` npm releases can be cut
**ad-hoc from `canary`** via the `Trigger Release` workflow, retiring
the dedicated long-lived preview branch. The GitHub environment has been
updated accordingly.
A preview cut produces **two commits**, pushed in a single update:
1. **Bump-to-preview** — all packages set to the computed preview
version, tagged `v…-preview.N`. This tag's build publishes `@preview`
(relies on #95085).
2. **Revert-to-canary** — restores the `-canary.N` versions so `canary`
keeps advancing its own line and isn't stranded on a preview version.
```
B canary HEAD before cut (e.g. 16.3.0-canary.61)
│
P v16.3.0-preview.N ← tag here; tag build publishes @preview
│
R canary HEAD after cut (versions restored to 16.3.0-canary.61)
```
### Preview version numbering
`base = max(canary major.minor.patch, npm @preview major.minor.patch)`:
- base still on the published preview line → continue it (`n + 1`)
- canary advanced to a higher base (or no `@preview` published) → reset
to `.0`
So if `canary` jumps to `18.0.0-canary.x` since the last
`16.3.0-preview.x`, the next cut is `18.0.0-preview.0`, not a
continuation.
## Test plan
The dry mode of `start-release.js` was extended to intercept the GH
requests and log the relevant data.
```console
$ node ./scripts/start-release.js --release-type preview --dry-run
Dry run: keeping commits locally, skipping git push and GitHub release creation
Running pnpm release-preview...
[...]
> lerna version 16.3.0-preview.4 --force-publish -y --no-push --allow-branch '**'
[...]
Creating GitHub-signed release commit(s) for v16.3.0-preview.4 from local commits 0f5c1e865cc34edb257a16823ed6525d9cd58bfc..0062348c411776271fe7eac64e97b8bad2775b77
[dry-run] GitHub API POST /repos/vercel/next.js/git/blobs [...]
[dry-run] GitHub API POST /repos/vercel/next.js/git/commits {"message":"v16.3.0-preview.4","tree":"0000000000000000000000000000000000000016","parents":["0f5c1e865cc34edb257a16823ed6525d9cd58bfc"]}
[dry-run] GitHub API POST /repos/vercel/next.js/git/commits {"message":"Restore canary version 16.3.0-canary.61 after v16.3.0-preview.4 preview release","tree":"000000000000000000000000000000000000002d","parents":["0000000000000000000000000000000000000017"]}
[dry-run] GitHub API POST /repos/vercel/next.js/git/refs {"ref":"refs/tags/v16.3.0-preview.4","sha":"0000000000000000000000000000000000000017"}
[dry-run] GitHub API PATCH /repos/vercel/next.js/git/refs/heads/sebbie/preview-release-from-canary {"sha":"000000000000000000000000000000000000002e","force":false}
Dry run: skipping local branch sync; would set sebbie/preview-release-from-canary to 000000000000000000000000000000000000002e and tag v16.3.0-preview.4 at 0000000000000000000000000000000000000017
Created GitHub-signed release tag v16.3.0-preview.4 at 0000000000000000000000000000000000000017; branch sebbie/preview-release-from-canary now at 000000000000000000000000000000000000002e
Dry run: skipping GitHub release creation
Release process is finished
```
I noticed the `node-version-file` option for `setup-node` while
reviewing https://github.com/vercel/nextjs-react-compiler/pull/2
We should use it in places where we're already checking out the
repository anyways. It should make it easier to keep node versions in
sync.
Previously we pinned all of these to their current versions at the time.
That meant that some of these got pinned to really old versions. This
updates all of the "first-party" `actions/*` dependencies.
Prompted claude with:
```
For all of these uses of actions/*, make sure we're pulling in the latest stable version (check the gh cli). When upgrading across major versions, fetch the release notes from the GH releases using the gh CLI and make sure that there are no problems that the upgrade will cause.
```
Claude read all the release notes and seems to think these upgrades are
safe.
If this action detects that you're likely using `npm` it (by default)
enables a cache for `npm`. We use `pnpm`, so it doesn't do anything (and
we manually set up a pnpm cache in some places), but the implicit
behavior here is a little dangerous: e.g.
https://adnanthekhan.com/posts/angular-compromise-through-dev-infra/#finding-the-pivot
So let's explicitly disable this everywhere. It wasn't doing anything
for us anyways.
Moves all release workflows off of a GH PAT and uses an app with a
short-lived token instead.
Test Plan:
Dry run
[here](https://github.com/vercel/next.js/actions/runs/24934593874).
However, this workflow is blocked until we figure out commit signing for
the bot app. Some options:
- The bot account generates a signing key and we use it in CI (not
great, bypasses the app)
- The org bypasses signature verification for the bot user (also not
great, requires an exemption rule)
- We need to rework the commit step so Lerna does not do the push, and
instead trigger it via the app + GH API. This seems like the best
option, will be added in a follow-up PR.
Note: `create-release-branch` workflow is broken in its current form, as
we will not be restoring administrator privileges to adjust environment
settings. This will become a manual step in the future.
Moves the `environment` into `publishRelease` rather than
`trigger_release` since the actual action we want to create environment
rules for is the publish step.
Re-submission of #91933. Had a problem with my fork and had to delete
it, which closed the original PR. Apologies for the noise.
## Summary
This PR pins all GitHub Actions to immutable commit SHAs instead of
mutable version tags and extracts expressions from `run:` blocks into
`env:` mappings.
- Pin 19 unpinned actions across workflow files to full 40-character
SHAs
- Add version comments for readability (e.g., `@abc123 # v1.0.9`)
- Extract 2 secrets and 5 workflow_dispatch inputs from run blocks to
env vars
## Changes by file
| File | Changes |
|------|---------|
| build_and_deploy.yml | Pinned ijjk/rust-cache, ast-grep/action,
taiki-e/install-action to SHA |
| build_reusable.yml | Pinned ijjk/rust-cache,
SimenB/github-actions-cpu-cores to SHA |
| cancel.yml | Pinned withgraphite/graphite-ci-action to SHA, extracted
GRAPHITE_TOKEN to env var |
| lock.yml | Pinned dessant/lock-threads to SHA |
| notify_slack.yml | Pinned slackapi/slack-github-action to SHA (2
instances) |
| publish_canary.yml | Extracted NPM_TOKEN_ELEVATED to env var |
| publish_release.yml | Extracted 5 workflow_dispatch inputs to env vars
|
| retry_deploy_test.yml | Pinned dtolnay/rust-toolchain to SHA |
| triage.yml | Pinned balazsorban44/nissuer to SHA |
| turbopack_benchmark.yml | Pinned taiki-e/install-action,
ijjk/rust-cache, CodSpeedHQ/action to SHA |
| turbopack_benchmark_wasm.yml | Pinned taiki-e/install-action,
CodSpeedHQ/action to SHA |
| turbopack_benchmark_xtask.yml | Pinned taiki-e/install-action,
CodSpeedHQ/action to SHA |
## Actions Pinned
| Action | Version | SHA |
|--------|---------|-----|
| ijjk/rust-cache | turbo-cache-v1.0.9 | a34594c45081... |
| ast-grep/action | v1.5.0 | cf62e780f0c8... |
| taiki-e/install-action | nextest / v2 | 3a0adb... / 7627fb... |
| withgraphite/graphite-ci-action | main | ee395f3a7825... |
| dessant/lock-threads | v5 | 1bf7ec25051f... |
| slackapi/slack-github-action | v1.25.0 | 6c661ce58804... |
| SimenB/github-actions-cpu-cores | v2 | 97ba232459a8... |
| dtolnay/rust-toolchain | stable | 631a55b12751... |
| balazsorban44/nissuer | 1.10.0 | 92ef22afd6a7... |
| CodSpeedHQ/action | v4 | 1c8ae4843586... |
## A note on internal action pinning
This PR pins all actions including org-owned ones. Best practice is to
pin everything \u2014 the tj-actions/changed-files attack was an
internally maintained action that was compromised, and every repo
referencing it by tag silently executed attacker code. That said, it's
your codebase. If you'd prefer to leave org-owned actions unpinned, let
us know and we'll adjust the PR.
## How to verify
Review the diff \u2014 each change is mechanical and preserves workflow
behavior:
- **SHA pinning**: `action@v3` becomes `action@abc123 # v3` \u2014
original version preserved as comment
- **Expression extraction**: `${{ expr }}` in `run:` moves to `env:`
block, referenced as `$ENV_VAR` in the script
- No workflow logic, triggers, or permissions are modified
I put up some research on this on
[Twitter](https://x.com/vigilance_one/status/2036581210663616729) and a
[research
site](https://www.vigilantdefense.com/research/github-top-50k-repos-cicd-security-scan)
if you want more context. I wrote a scanner called Runner Guard and open
sourced it [here](https://github.com/Vigilant-LLC/runner-guard).
If you have any questions, reach out. I'll be monitoring comms.
\\- Chris Nyhuis (dagecko)
---------
Co-authored-by: Benjamin Woodruff <github@benjam.info>
Co-authored-by: Benjamin Woodruff <benjamin.woodruff@vercel.com>
<!-- Thanks for opening a PR! Your contribution is much appreciated.
To make sure your PR is handled as smoothly as possible we request that you follow the checklist sections below.
Choose the right checklist for the change(s) that you're making:
## For Contributors
### Improving Documentation
- Run `pnpm prettier-fix` to fix formatting issues before opening the PR.
- Read the Docs Contribution Guide to ensure your contribution follows the docs guidelines: https://nextjs.org/docs/community/contribution-guide
### Fixing a bug
- Related issues linked using `fixes #number`
- Tests added. See: https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs
- Errors have a helpful link attached, see https://github.com/vercel/next.js/blob/canary/contributing.md
### Adding a feature
- Implements an existing feature request or RFC. Make sure the feature request has been accepted for implementation before opening a PR. (A discussion must be opened, see https://github.com/vercel/next.js/discussions/new?category=ideas)
- Related issues/discussions are linked using `fixes #number`
- e2e tests added (https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs)
- Documentation added
- Telemetry added. In case of a feature if it's used or not.
- Errors have a helpful link attached, see https://github.com/vercel/next.js/blob/canary/contributing.md
## For Maintainers
- Minimal description (aim for explaining to someone not on the team to understand the PR)
- When linking to a Slack thread, you might want to share details of the conclusion
- Link both the Linear (Fixes NEXT-xxx) and the GitHub issues
- Add review comments if necessary to explain to the reviewer the logic behind a change
### What?
### Why?
### How?
Closes NEXT-
Fixes #
-->
- update codemod script
- upgrade both release scripts, not sure which one is correct
<!-- Thanks for opening a PR! Your contribution is much appreciated.
To make sure your PR is handled as smoothly as possible we request that
you follow the checklist sections below.
Choose the right checklist for the change(s) that you're making:
## For Contributors
### Improving Documentation
- Run `pnpm prettier-fix` to fix formatting issues before opening the
PR.
- Read the Docs Contribution Guide to ensure your contribution follows
the docs guidelines:
https://nextjs.org/docs/community/contribution-guide
### Fixing a bug
- Related issues linked using `fixes #number`
- Tests added. See:
https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs
- Errors have a helpful link attached, see
https://github.com/vercel/next.js/blob/canary/contributing.md
### Adding a feature
- Implements an existing feature request or RFC. Make sure the feature
request has been accepted for implementation before opening a PR. (A
discussion must be opened, see
https://github.com/vercel/next.js/discussions/new?category=ideas)
- Related issues/discussions are linked using `fixes #number`
- e2e tests added
(https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs)
- Documentation added
- Telemetry added. In case of a feature if it's used or not.
- Errors have a helpful link attached, see
https://github.com/vercel/next.js/blob/canary/contributing.md
## For Maintainers
- Minimal description (aim for explaining to someone not on the team to
understand the PR)
- When linking to a Slack thread, you might want to share details of the
conclusion
- Link both the Linear (Fixes NEXT-xxx) and the GitHub issues
- Add review comments if necessary to explain to the reviewer the logic
behind a change
### What?
### Why?
### How?
Closes NEXT-
Fixes #
-->
---------
Co-authored-by: graphite-app[bot] <96075541+graphite-app[bot]@users.noreply.github.com>
Co-authored-by: JJ Kasper <jj@jjsweb.site>
## What
Update the napi cli to the latest 2x build 2.18.4
## Why
This will make it easy to pass custom cargo profiles to napi, which will make it easier to enable debug assertions, which will happen in a followup.
Part-of PACK-4578
This fixes our workflow for checking if a new canary should be
published. `actions/checkout` won't include the latest tag information
so this uses the old clone workflow while still preserving branch
specific checkout behavior to support backports
<!-- Thanks for opening a PR! Your contribution is much appreciated.
To make sure your PR is handled as smoothly as possible we request that
you follow the checklist sections below.
Choose the right checklist for the change(s) that you're making:
## For Contributors
### Improving Documentation
- Run `pnpm prettier-fix` to fix formatting issues before opening the
PR.
- Read the Docs Contribution Guide to ensure your contribution follows
the docs guidelines:
https://nextjs.org/docs/community/contribution-guide
### Adding or Updating Examples
- The "examples guidelines" are followed from our contributing doc
https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md
- Make sure the linting passes by running `pnpm build && pnpm lint`. See
https://github.com/vercel/next.js/blob/canary/contributing/repository/linting.md
### Fixing a bug
- Related issues linked using `fixes #number`
- Tests added. See:
https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs
- Errors have a helpful link attached, see
https://github.com/vercel/next.js/blob/canary/contributing.md
### Adding a feature
- Implements an existing feature request or RFC. Make sure the feature
request has been accepted for implementation before opening a PR. (A
discussion must be opened, see
https://github.com/vercel/next.js/discussions/new?category=ideas)
- Related issues/discussions are linked using `fixes #number`
- e2e tests added
(https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs)
- Documentation added
- Telemetry added. In case of a feature if it's used or not.
- Errors have a helpful link attached, see
https://github.com/vercel/next.js/blob/canary/contributing.md
## For Maintainers
- Minimal description (aim for explaining to someone not on the team to
understand the PR)
- When linking to a Slack thread, you might want to share details of the
conclusion
- Link both the Linear (Fixes NEXT-xxx) and the GitHub issues
- Add review comments if necessary to explain to the reviewer the logic
behind a change
### What?
### Why?
### How?
Closes NEXT-
Fixes #
-->
Closes NEXT-2784
Jimmy Miller
