`pnpm dlx` isn't using a lockfile. Using the self-contained binary from
GitHub and validate the checksum lets us effectively pin `datadog-ci`
and all of its possible transitive dependencies.
This is a follow-up for
https://vercel.slack.com/archives/C0APPN2LC83/p1775073127894859
(cherry picked from commit 631fae951d)
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.
(cherry picked from commit e69de2ffaf)
Moves the `environment` into `publishRelease` rather than
`trigger_release` since the actual action we want to create environment
rules for is the publish step.
(cherry picked from commit 2b846de4c5)
Switches from a long-lived token to trusted publishing OIDC flow. This requires a bump to Node (for feature support). Otherwise just dropping unnecessary envs.
(cherry picked from commit 129896c2e4)
Switch CI from self-hosted runners to GitHub-hosted runners and fix the
follow-up issues that showed up once the hosted jobs were exercised.
- Move Linux workflows onto `ubuntu-latest-16-core-oss`, Windows
workflows onto `windows-latest-8-core-oss`, and the native mac release
lane onto `macos-15-intel`.
- Update the reusable build workflow to work in hosted environments by
relying on `runner.os` instead of label string matching, and by removing
the hardcoded `/home/runner` `fnm` path.
- Make Turbo/sccache configuration explicit for hosted runners:
- unify on `vtest314-next-adapter-e2e-tests`
- pass `TURBO_TOKEN` via workflow env/secrets instead of assuming
runner-level env
- switch Turbo cache mode to `local:rw,remote:rw` so jobs still have
local cache behavior when remote cache is unavailable
- Update the `sccache` action defaults/docs to use the hosted-runner
secret setup (`TURBO_TOKEN`) instead of the old self-hosted token
wiring.
- Make Datadog reporting fail open so missing `DATA_DOG_API_KEY` does
not block CI.
- Fix the CLI reserved-port test so it asserts Next’s own `-p 1`
validation instead of failing earlier on hosted Linux due to
privileged-port binding.
- Replace the live `musl.cc` dependency in `native-builder.Dockerfile`
with musl sysroots imported from GHCR-hosted `rust-musl-cross` images,
keeping the existing `/opt/*-cross` layout used by the Linux native
build scripts.
- Fix the macOS native build workaround s so it applies to all
*-apple-darwin targets based on the Cargo target OS rather than the host
architecture, which avoids napi-build injecting the unsupported -Wl
linker arg when @next/swc is linked with rust-lld on hosted mac runners.
Test Plan:
- This PR's CI
- This
[build_and_deploy](https://github.com/vercel/next.js/actions/runs/24865715983/job/72801225722)
job running on every arch
## Summary
- Backport of #92123 to `next-16-2` release branch
- Cherry-picked the CSS HMR Safari fix and regenerated turbopack-tests
snapshot goldens for the release branch
## Test plan
- [x] `UPDATE=1 cargo nextest r -p turbopack-tests` — all 297 tests pass
- [x] `pnpm build-all` — clean build, no issues with
`generated-native.d.ts`
## What
Fixes the `test cargo unit` CI job which has been consistently timing out (30 min) on canary since #91343 landed on Mar 14.
## Why
Two issues were contributing to the timeout:
1. **LTO on unit test binaries**: #91343 added `lto = "thin"` to `[profile.release]`. The `release-with-assertions` profile (used by `test-cargo-unit`) inherits from `release`, so it inherited LTO. Unlike the native binary build which only links one artifact, `cargo nextest run --workspace` builds test binaries for dozens of crates — each requiring its own LTO link pass. This pushed the build from ~8 minutes to 30+ minutes, exceeding the job timeout.
2. **No remote cache timeout or streaming output**: The `turbo run test-cargo-unit` command had no `--remote-cache-timeout` (unlike the build step which uses `--remote-cache-timeout 60`) and used turbo's default grouped log output, which buffers all output until the task completes. This made the job appear completely silent for 30 minutes before being killed, making it impossible to diagnose.
## How
- Added a `release-with-assertions-no-lto` cargo profile that inherits from `release-with-assertions` but disables LTO, and switched `test-cargo-unit` to use it. The production native build continues to use `release-with-assertions` with LTO.
- Added `--remote-cache-timeout 60 --log-order stream` to the turbo command for `test-cargo-unit` for parity with the build step and real-time output visibility.
# What
Add `lto = "thin"` to the workspace-level `[profile.release]` in
`Cargo.toml`.
# Why
Thin LTO enables cross-crate optimization at link time, improving
runtime
performance of the final artifacts (next-napi-bindings native module,
turbopack-cli binary, and benchmarks) without the full build time cost
of
fat LTO.
# How
Added `lto = "thin"` to the workspace root `[profile.release]` section.
This applies to all release-profile link targets in the workspace,
including
binaries, cdylibs, and benchmarks. The `release-with-assertions` and
`release-with-debug` profiles inherit from `release`, so they also
benefit.
We've had a longstanding issue where you'd have to run `pnpm i` _twice_ on a fresh checkout because `pnpm` wouldn't set up binary symlinks until after the binary exists, but the binary wouldn't exist until after `pnpm build` was done:
https://github.com/vercel/next.js/blob/canary/.github/workflows/build_reusable.yml#L303-L311
This solves that problem using a pnpm preinstall script that creates stub binaries for these files if they don't exist yet (because we haven't run `pnpm build`).
## Test Plan
```
git clean -fxd
pnpm i
pnpm build
pnpm test-start test/e2e/app-dir/next-image/
pnpm test-start-turbo test/e2e/app-dir/next-image/
```
I tested this both locally and inside of a fresh ubuntu VM.
Running `pnpm next` after `pnpm i` but before `pnpm build` gives a helpful error message:
<img width="946" height="125" alt="Screenshot 2026-03-06 at 9 37 14 PM" src="https://github.com/user-attachments/assets/4517e8bd-60ca-44f2-a34c-f7f3ec56c634" />
Preview builds served via `vercel-packages.vercel.app` were showing the
published canary version instead of the PR-specific preview version.
This happened because `create-preview-tarballs.js` updated
`package.json` after the build, but the version was already baked into
the compiled `dist/` files by `setNextVersion` in `taskfile-swc.js`.
This extracts the version computation from `create-preview-tarballs.js`
into a new `set-preview-version.js` script that runs before `pnpm run
build`, so the compiled output naturally includes the correct version.
`create-preview-tarballs.js` now reads the version from
`packages/next/package.json` instead of computing it independently.
## Test Plan
1. Create a new app: `pnpm create next-app@canary`
2. Install the preview build from this PR: `pnpm i
https://vercel-packages.vercel.app/next/commits/06681c21e886a97e39d277808780884151c00318/next`
3. Run `pnpm dev` and inspect `next.version` in DevTools — should show
`16.2.0-preview-06681c21-20260306` instead of the canary version
The recent Cached Navigations feature introduced navigation-level
caching into the segment cache, where static and dynamic RSC data from
navigations and initial HTML loads is cached so that repeat visits can
be served instantly. This feature is currently gated behind
`cacheComponents`, meaning it activates for all projects that enable
Cache Components.
This change introduces a new `experimental.cachedNavigations` flag that
independently controls the Cached Navigations behavior. The flag
defaults to `false` so we can investigate potential regressions that the
feature might have introduced without affecting the broader Cache
Components functionality.
The flag requires `cacheComponents` to also be enabled and throws a
configuration error if `cachedNavigations` is set without it. On the
server, the staged rendering paths in `app-render.tsx` (both RSC request
handling and initial HTML rendering) now check `cacheComponents &&
cachedNavigations` before producing staged responses. On the client,
`process.env.__NEXT_EXPERIMENTAL_CACHED_NAVIGATIONS` is used alongside
`process.env.__NEXT_CACHE_COMPONENTS` for compile-time dead code
elimination in the stream tee (`app-index.tsx`) and the response
processing (`fetch-server-response.ts`).
The cached navigations test suite enables the flag via `next.config.ts`,
and the Cache Components CI jobs export
`__NEXT_EXPERIMENTAL_CACHED_NAVIGATIONS=true` to maintain test coverage.
### What?
Add `aurorascharff` to the devex team labeler configuration.
### Why?
New team member onboarding.
### How?
Added username to the relevant pattern entries in the labeler config.
---------
Co-authored-by: vercel[bot] <35613825+vercel[bot]@users.noreply.github.com>
The previous method of using the PR endpoint under the hood calls the
GitHub API to get the commit SHA, which is a waste of resources, so just
use the commit SHA directly in the tarball URL.
## Summary
- Adds `cleanupScriptPath` workflow dispatch input and
`NEXT_TEST_CLEANUP_SCRIPT_PATH` env var to `test_e2e_deploy_release.yml`
(webpack + turbopack jobs)
- Adds `cleanupUsingCustomScript()` method to `NextDeployInstance`
following the same pattern as the existing deploy and logs scripts
- Calls the cleanup script in `destroy()` before existing teardown logic
---------
Co-authored-by: Vercel <vercel[bot]@users.noreply.github.com>
## Summary
For context we discovered jobs were not reliably always running in
https://github.com/vercel/next.js/pull/90668 as addapters + turbopack
group ran more tests than just turbopack group.
- Each sharded test sub-job independently fetched test timings from KV
via a turbo task. Because turbo cache keys can vary across job groups
and KV can return slightly different data at different times, the
sharding algorithm produced different test-to-shard assignments across
groups — causing some tests to be missing entirely and others to run in
multiple shards.
- Adds a `--require-timings` flag to `run-tests.js` that fails loudly if
`test-timings.json` can't be loaded from disk, preventing silent
fallback to KV or round-robin.
- Adds a `testTimingsArtifact` input to `build_reusable.yml` that
downloads a pre-built timings artifact instead of fetching via turbo.
When unset (default), existing behavior is preserved.
- In both `test_e2e_deploy_release.yml` and `build_and_test.yml`,
timings are now fetched once in a setup job, uploaded as a GitHub
artifact, and downloaded by all sub-jobs — guaranteeing identical shard
assignments across all job groups.
## Test plan
- [ ] Verify `build_and_test.yml` jobs pick up the shared `test-timings`
artifact
- [ ] Verify `test_e2e_deploy_release.yml` deploy jobs pick up the
shared `test-timings` artifact
- [ ] Verify workflows that don't pass `testTimingsArtifact` (e.g.
`integration_tests_reusable.yml`, `pull_request_stats.yml`) still use
the turbo fallback path unchanged
<!-- 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: JJ Kasper <jj@jjsweb.site>
<!-- 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 #
-->
This should reduce some duplicate CI jobs.
This split existed to support separate dev/prod manifests for skipping tests. That's not needed anymore, so we can just switch to the Webpack setup. This manual partitioning of `integration` tests into dev vs prod was brittle anyway
We still need this setup for rspack though
This avoids cancelling on canary branch when a commit is merged while
previous commit is still running
## Summary
- keep cancel-in-progress behavior for pull_request runs
- stop canceling in-progress runs for follow-up pushes to canary by
using a per-run concurrency group for push events
x-ref:
https://github.com/vercel/next.js/actions/runs/22113161316/job/63914496141
Fork the set of deployment tests so they run with both turbopack and
webpack. Now that turbopack is the default bundler we need this
coverage.
Because we are now running twice as many tests, decrease concurrency,
otherwise we hit rate limits on vercel. There were attempts to improve
rate limit recovery in the vercel CLI
(https://github.com/vercel/vercel/pull/14443 and
https://github.com/vercel/vercel/pull/14407) which helped but did not
solve the issue. Also there was an investigation into the API service
where we discovered some suspicious but ultimately correct code
(https://github.com/vercel/api/pull/55967).
The basic issue is that the vercel CLI polls `api-deployments-get`
fairly aggressively at the beginning of a deploymnet, and since we start
so many deployments in parallel we will always hit the rate limits. The
recovery logic in the CLI is good but has (reasonably) a fixed set of
retries it will attempt, inevitably some tasks get unlucky. So retrying
the test does work, but really we should slow down which is what we do
here. 😥https://github.com/vercel/next.js/actions/runs/20290161194/job/58272593085
Fixes PACK-5613
---------
Co-authored-by: JJ Kasper <jj@jjsweb.site>
## Summary
- fix flaky `pnpm install` failures in the stats action caused by
cross-device hardlinking (`ERR_PNPM_EXDEV`)
- force `pnpm` to use `--package-import-method=copy` for installs run in
temp repos
- apply the same setting in both install paths used by the stats
workflow
x-ref:
https://github.com/vercel/next.js/actions/runs/22110883672/job/63906643545
We don't need/want preview builds for these base branches, it's a waste
of CI capacity.
Relevant docs:
https://docs.github.com/en/actions/reference/workflows-and-actions/workflow-syntax#onpushbranchestagsbranches-ignoretags-ignore
> Use the branches filter when you want to include branch name patterns
or when you want to both include and exclude branch names patterns. Use
the branches-ignore filter when you only want to exclude branch name
patterns. You cannot use both the branches and branches-ignore filters
for the same event in a workflow.
> If you define only tags/tags-ignore or only branches/branches-ignore,
the workflow won't run for events affecting the undefined Git ref. If
you define neither tags/tags-ignore or branches/branches-ignore, the
workflow will run for events affecting either branches or tags.
## Enable Rust backtraces in CI tests
### What?
Added `RUST_BACKTRACE=1` environment variable to all Turbopack-related test workflows.
### Why?
This change enables detailed Rust backtraces when Turbopack encounters errors during CI tests, making it easier to diagnose and fix issues that occur in the Rust components.
Notably, some assertions/panics are about detecting race conditions, e.g.
```
thread 'tokio-runtime-worker' (1056161) panicked at turbopack/crates/turbo-tasks-backend/src/backend/operation/mod.rs:426:13:
Concurrent task lock acquisition detected. This is not allowed and indicates a bug. It can lead to deadlocks.
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
```
Rather than painfully attempting to reproduce locally we can just run with the env var all the time and perhaps that will be enough to figure out rare issues
Just plumbing and enabling that flag in the experimental shards. The flag will enable our Layout router to use Fragment refs for scroll restoration. Implementation will be done in a follow-up.
Disclaimer: This PR is entirely claude+opencode generated.
- Crate name said `next-swc-napi`, which was confusing, because this has a lot more than swc bindings nowdays.
- The crate name didn't match the directory name, which often confused agents.
This does not change the npm package name, as that would likely have a much larger blast radius, and could break more things, to a point where it may not be worth it.
<!-- 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 #
-->
This updates to run the entire E2E deploy tests same as we do currently
but with adapters enabled to catch regressions there. These run on a
separate test team to isolate from existing test team and avoid rate
limits.
Test run of the workflow done here
https://github.com/vercel/next.js/actions/runs/21418745794
The warnings from `baseline-browser-mapping` about outdated data fail some tests that don't expect the CLI output. By updating the dependency we avoid showing the warning for now, and by setting the environment variable `BASELINE_BROWSER_MAPPING_IGNORE_OLD_DATA` we should silence any future warnings as well.
related:
- #86625
- #86653
## Summary
Renames the CI job display names from 'Test new tests' to 'Test new and
changed tests' to accurately reflect what these jobs do.
The `get-changed-tests.mjs` script uses `git diff --name-only` which
detects both added and modified files, so the job names should reflect
that they test both new AND changed test files.
This applies fixes for outputs in `onBuildComplete` with various slight
differences from expected values. This also applies some fixes in the
route-module interface to ensure we install the process handlers for PPR
since currently that was done in `next-server` which we want to get rid
of and there was an edge case with query parsing logic in the
route-module.
Our E2E tests were run against this here to validate
https://github.com/vercel/next.js/actions/runs/21324578779 and failures
are matching existing failures on canary.
x-ref: https://github.com/nextjs/adapter-vercel/pull/11
x-ref: https://github.com/vercel/vercel/pull/14574
---------
Co-authored-by: vercel[bot] <35613825+vercel[bot]@users.noreply.github.com>
The recent change to always run all tests without aborting on failure
(#88435) inadvertently broke manifest generation. Previously, test
output was emitted for all tests when `NEXT_TEST_CONTINUE_ON_ERROR` was
set, but that variable was removed. Now test output is only emitted for
failing tests, causing the manifest to lose all passing test entries.
This adds a new `NEXT_TEST_EMIT_ALL_OUTPUT` environment variable that
restores the full output behavior specifically for the manifest
generation workflows.
Part of https://linear.app/vercel/issue/NAR-719/
We previously only supported a single manifest for filtering tests. However, Cache Component deploy tests have two manifests. Now we merge manifests append-only.
## Test plan
- [x] https://github.com/vercel/next.js/pull/88821 adds a failed deploy test to a test suite also listed in the CC manifest. Tests from CC and deploy manifest are skipped
```console
$ NEXT_EXTERNAL_TESTS_FILTERS="test/deploy-tests-manifest.json,test/cache-components-tests-manifest.json" NEXT_TEST_MODE=deploy node run-tests.js -c 1 --retries 0 test/e2e/app-dir/searchparams-reuse-loading/searchparams-reuse-loading.test.ts
○ skipped should re-use loading from "full" prefetch for param-full URL when navigating to param-less route
○ skipped should re-use loading from "full" prefetch for param-less URL when navigating to param-full route
○ skipped should re-use loading from "full" prefetch for param-full URL when navigating to param-full route
when aliasing is skipped
✕ should work for not found pages
✕ should work for route handlers
✕ should work for navigating to pages dir
Without Middleware
✕ should correctly return different RSC data for full prefetches with different searchParam values
With Middleware
○ skipped should correctly return different RSC data for full prefetches with different searchParam values
```
Benjamin Woodruff