Cleans up unused workflows & scripts
- bankrupt workflow is superseded by the [stale
workflow](https://github.com/vercel/next.js/blob/canary/.github/workflows/issue_stale.yml)
- filtering issues by version hasn't been used in 9 months and can be
accomplished with a GH search
- the AI triaging tool has largely been more noise than signal. the
existing alerts that have been surfaced in the triage channel have been
sufficient
Looks like when the retry workflow is triggered from the release
workflow it doesn't have the default input like it should so this adds
the fallback inline for the run-name.
This step was causing the front-sync job to fail. I'm not totally sure
how it was working before, some other workflow must have logged logged
in at some point. This is just a debug step anyway, so I think we can
delete it. **I confirmed that the next step worked just fine.** We could
also add a step that runs `gh login` if we think it would actually be
useful.
The front-sync job has been running directly have new versions are
published, but deployment tests only run after a release as well. This
PR runs the front-sync job after the deployment tests. There is a new
input on the workflow the front-sync triggers to immediately close the
PR that gets opened in that repo that will get set to true if the tests
fail. It is still beneficial to open a PR so we can more easily bisect
problematic releases.
See thread for discussion:
https://vercel.slack.com/archives/C08V7CU57E1/p1751053430834889
<!-- 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 #
-->
---------
Co-authored-by: graphite-app[bot] <96075541+graphite-app[bot]@users.noreply.github.com>
Co-authored-by: JJ Kasper <jj@jjsweb.site>
### What?
Apply same changes as https://github.com/swc-project/swc/pull/10711 to next.js/turbopack. We now run benchmark on `canary` branch in parallel.
### Why?
`codspeed` says `New benchmark` quite frequently, but it's not. This PR should fix it
## Enable debug assertions in CI
### What?
Build using `--profile release-with-assertions` for all tests in CI. A previous PR (https://github.com/vercel/next.js/pull/80511) enabled them for unit tests, this completes the effort for e2e tests run in CI.
There is one exception. The production tests currently have a failing assertion for duplicate modules, so a new env var (`TURBOPACK_TEMP_DISABLE_DUPLICATE_MODULES_CHECK`) is introduced to disable that exact check to allow this to be landed.
### Why?
Debug assertions help catch bugs early by validating assumptions in the code. By enabling them in tests, we can improve quality
### How?
- Added a new `rustBuildProfile` parameter to the reusable build workflow to control the build profile
- Created a new `build-native-release-with-assertions` script in next-swc to set the cargo profile
- Updated the turbopack production tests to set the opt out variable
Part-of PACK-4578
## 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
- Follow the naming conventions of other environment variables and prefix `TEST_WASM` with `NEXT_TEST_WASM` so that there's less chance of conflicts with user code
- Remove the logic in `setup-wasm.mjs` that modifies the repository (not great for running tests locally) and instead try to match the environment-variable-override behavior used for native (non-wasm) bindings via `NEXT_TEST_WASM_DIR`.
- Hard-fail if `NEXT_TEST_WASM` is set and we fail to load wasm bindings instead of silently using fallback logic that loads native bindings instead.
- We don't need to install `wasm-pack` with `curl | sh` for tests: `pnpm` already installs it (and pins a specific version).
- The whole dance of renaming the directory from `pkg` to `pkg-nextjs` is a hack we use when publishing the package, as we're building both "web" and "nextjs" targets. We don't need to do that for tests.
- Fix handling of `undefined` values in SWC options objects.
- Remove hacks for Next v12.2
### What?
Retry HMR benchmarks, but make it less flaky.
This PR
- Removes flaky benchmarks (`hmr_initial_compilation`, `hmr_subscription`)
- Moves flaky parts (`benchmark_initial_compilation`) out of the iteration loop by moving them to the setup phase.
### Why?
We need a stable benchmark for dev performance.
### What?
Configure HMR benchmark. I'm not sure if this benchmark would be stable enough, but let's try.
I'll remove this from the automated benchmark later this week if it turns out to be flaky.
### Why?
x-ref: https://vercel.slack.com/archives/C06PPGZ0FD3/p1748943158878159
### How?
Closes PACK-4758
### What?
Removes `benchmark-tiny` which _was_ stable at the time of introduction, but is not stable anymore.
### Why?
It makes interpreting the performance difference harder
### What?
User the custom runner for turbopack benchmarks
### Why?
Turbopack is very parallel so it's better to use custom runners which has more CPU cores.
### What?
This PR configures an automated benchmark for turbopack. We can run small benchmarks for all turbopack PRs, and I'll add more benchmarks with follow-up PRs.
### Why?
We need a way to track performance consistently.
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.
### Why?
The `process.env.RELEASE_TYPE` handling was set incorrectly. It
should've been set to the "trigger" workflow, but instead, it was set to
the "publish" workflow. Therefore, the "publish" workflow needs to know
which dist tag to set for publish.
---------
Co-authored-by: Sebastian Sebbie Silbermann <sebastian.silbermann@vercel.com>
This PR adds a step to send Slack notifications of the status of the
release.
---------
Co-authored-by: Sebastian "Sebbie" Silbermann <sebastian.silbermann@vercel.com>
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>
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>
Same basic idea as https://github.com/vercel/next.js/pull/78787
This test suite has a lot of timeouts with rspack, which causes it to take a long time to run (though not quite long enough that it breaks the job).
In general, large test suites are good to break up, because they benefit from parallelism.
Test retries are important because of our high test flakiness. Without
this, we may get false-positive failures detected in the manifests and
the arewerspackyet dataset.
We had to disable test retries for arewerspackyet tests because we were
suffering from timeouts in CI. Since then we've fixed this in a number
of ways:
- I broke 5 large test suites that were contributing most to long job
execution duration when timing out into smaller test suites that can run
in parallel.
- I reduced the per-test timeout from 4 minutes back down to 1 minute
(same as the webpack tests use) for both Rspack and Turbopack.
- The Rspack team fixed the underlying regressions that were causing
increased test failures in our CI. 🙏
- Going forward, I'm working on running Rspack CI in more places, so a
regression on tests is will be much less likely in the first place.
Rspack test runs are taking <20 minutes (with a 90 minute timeout), so
it seems safe to add back the default 2 retries!
This only impacts the nightly arewerspackyet CI runs, so the CI capacity
hit from retries shouldn't be too significant.
Sebastian "Sebbie" Silbermann