As we're using nodejs with latest version of 18.x on CI, there's a new behavior change of `url.fileURLToPath` that didn't join the paths as expected
locally with node 16.x or 18.16
```
/private/var/folders/mh/y8kwzkls6v3_w3_k6q384cw80000gn/T/next-install-b033b516612809c6fb0a0de77c6e50f7d7f8af34dfd3d01812b99345352dc992/node_modules/.pnpm/file+..+next-repo-7e52b07043e986127273a2d951e5c412b0dd45fb24eb34001bd372e2afff79db+packages+n_vyqu6i4c4i3efp5pqsaeaoe5s4/node_modules/next/dist/compiled/@vercel/og/noto-sans-v27-latin-regular.ttf
```
in the actions runner with node 18.17 it's
```
/tmp/next-install-8efaa47c1546bed07990d8f130decceb6536e1a36146e7885cb68e3c3dea21f7/node_modules/.pnpm/file+..+next-repo-9679355e05341947e7aa0b42c994e3ac_krcuriy4thl7zawouf7sswlrgy/node_modules/next/dist/compiled/@vercel/og/index.node.js/../noto-sans-v27-latin-regular.ttf
```
You can see that `index.node.js` is still present in the path as a folder which is unexpected
```
index.node.js/../
```
x-ref: https://github.com/vercel/next.js/actions/runs/5600417148/jobs/10242827739?pr=52790
### What?
Scale up concurrency on integration tests to be ~10min each
### Why?
This should bring down the total runtime of the CI
Co-authored-by: kodiakhq[bot] <49736102+kodiakhq[bot]@users.noreply.github.com>
Co-authored-by: Steven <steven@ceriously.com>
### What?
Adding a new label comment for "please simplify reproduction".
### Why?
During triaging, a lot of time is gone into trying to isolate the actual bug being reported. Reproductions sometimes contain unrelated code - that sometimes can be the actual cause of an issue, reported as a bug in Next.js, or require third-party services, secrets, setting up databases, and other tasks that take up much of the resources before the issue can even be verified.
### How?
Similar to the `please add a complete reproduction` and `please verify canary` labels, if a maintainer adds the `please simplify reproduction` label, an automatic comment will appear on the issue, asking for a minimal reproduction
[Slack thread](https://vercel.slack.com/archives/C04DUD7EB1B/p1685527818400339)
### What?
Closes WEB-1157. PR enables turbopack to support native webp encode / decode. There is one platform we can't support this (aarch64-linux-gnu) which disables those.
### What?
Add all passing tests
### Why?
We enforced that they all run turbopack and these are passing.
If any of these tests would become red, that indicated a problem.
### What?
this forces all tests to use turbopack independent of the way they invoke next dev
### Why?
some tests were not running turbopack
fixes WEB-1187
This PR migrates and adapts the [validate docs links script from `next-site`](https://github.com/vercel/front/pull/23185). This script is triggered by a GitHub action whenever a file in the `/docs` folder is updated. If broken links are found in the docs, the check fails and we post a comment on the PR with a list of broken links.
Co-authored-by: Michael Novotny <446260+manovotny@users.noreply.github.com>
Reverts vercel/next.js#51406
This pnpm bump seems to be causing lockfile issues with the react
versions which causes context issues since we need to share the same
react version in the monorepo.
### What?
Fixespnpm/pnpm#6424
### Why?
So users of Node 20 can contribute to Next.js
### How?
Upgrades pnpm with back compatibility to patch `ERR_INVALID_THIS` error.
If Node 14 support isn't necessary, I'd recommend upgrading to pnpm 8
for continued feature support and committing the lockfile.
---------
Co-authored-by: JJ Kasper <jj@jjsweb.site>
### What?
WEB-1150.
This PR is an attempt to upload next.js's test results into datadog test trace to track its status.
Originally it tried to use automatic trace injection (dd-trace/ci/init). However, due to some of custom environments / setup we use it was not compatible out of the box. Instead, this PR injects a new test reportert to generate junit report, then upload it at once at the end of the testing pipeline.
The reporter is configured to run when necessary variables set, local run should not be affected.
One thing to note is this report will not count retry results, as it'll create duplicated test entry with multiple results since we runts jest per individual test. This'll allow to detect flaky test easier, but also it means we'll get bit of skewed test results compare to the real world as first failure will be accounted as test fail immediately.
### What?
* enable turbopack tests in new CI
* split pre-build step into native and JS builds to allow to start
native tests faster
* update swc_core to sync with turbo
* update turbopack
### Why?
Running our test suite is still important as long we don't have the full
integration test suite enabled.
### Turbopack updates
* https://github.com/vercel/turbo/pull/5215 <!-- OJ Kwon - ci(workflow):
upload benchmark results to datadog -->
* https://github.com/vercel/turbo/pull/5239 <!-- OJ Kwon -
fix(swc_plugin): use shared runtime -->
* https://github.com/vercel/turbo/pull/3090 <!-- CHEN Yuan - Docs: prior
to run testcases, add guides to install dependencies for testcases. -->
* https://github.com/vercel/turbo/pull/5264 <!-- Tobias Koppers - update
test runner -->
---------
Co-authored-by: JJ Kasper <jj@jjsweb.site>
### What?
context: https://github.com/vercel/next.js/actions/runs/5231928600/jobs/9446394605#step:16:33
For some reason, installing datadog cli on some action runner (Windows) is unexpectedly slow: while other platform takes ~30s, windows only takes more than > 7m.
PR updates workflow logic to consolidate artifacts, and then send metrics at once on a separate ubuntu workflow.
Currently this is uploading every time the job is run even if it's a
cache hit and this step can take over 3 minutes un-necessarily so this
skips it if a cache hit occurred.
### What?
Another attempt to https://github.com/vercel/next.js/pull/50619 and WEB-1150, trying to apply setup guard more throughly.
I still do not know why original PR passed CI but fails to subsequent PRs after merge, but hope this could be a right guard to prevent unexpected failures.
### Description
Set some environment variables that reduce size on disk and make the
build a little faster.
Also, read the toolchain from the `rust-toolchain` file, so it's not
duplicated in every workflow.
Ported over from the `turbo` repo.
Updates to re-use our build workflow so turbo remote cache is leveraged
and updates re-usable workflow reference to be the same branch instead
of main.
This adds uploading the turbo run summaries for our publish builds so we
can debug cache misses there easier the same as the new build_reusable
workflow.
### What?
This PR updates existing CI worfklow for building Turbopack (`@next/swc`), and report its bytesize per target triple as additional metrics. It will be included in datadog's pipeline execution traces.
It would be better to track this per-PR, or per-commits but building all native binaries per each commit is too expensive. For now, tracking it when we deploy and actually build new release binaries.
### What?
This PR attempts to enable datadog trace integrations to the next.js integration tests if env is configured. With this, datadog can observe each test suite's results and detect some meaningful information (i.e flaky) for us.
However, I wasn't able to verify this works with next.js repo since for some reason CI worker does not pick up the api key in the env (https://vercel.slack.com/archives/C04KC8A53T7/p1685597124894539). Still this won't affect existing workflow, and once enabled I can test it over vercel/turbo repo instead.
Partially resolved WEB-1150.
### What?
This PR allows to trigger subset of build-and-deploy workflow manually via gh actions UI.
### Why?
Turbopack time to time requires to validate its changes against all of the platforms we build. Adding manual workflow allows to test it easier.
It tries to guard release check `isRelease` only if it comes from normal event (non manual dispatch) to avoid accidental publish workflow.
Ensures we continue pre-building binaries on merge to canary and ensures
we are testing against the maintenance Node.js version also adds turbo
summarize for all swc builds.
This breaks up some of our longest running tests which allows more
parallelizing of the tests. This also moves turbopack tests filtering
back to an allow list as it is running a lot of unrelated tests
currently which isn't ideal. We should only be running against tests
that are explicitly testing turbopack e.g. build tests should not be
duplicated in the turbopack group.
```sh
test/integration/css/test/group-1.test.js: 762.655
test/integration/edge-runtime-module-errors/test/index.test.js: 695.309
test/integration/css/test/group-2.test.js: 671.848
test/integration/i18n-support/test/index.test.js: 518.173
test/integration/scss-modules/test/index.test.js: 451.704
test/integration/css-features/test/index.test.js: 417.318
test/integration/css-modules/test/index.test.js: 403.405
test/integration/eslint/test/index.test.js: 381.563
test/integration/500-page/test/index.test.js: 371.134
test/integration/telemetry/test/index.test.js: 367.691
test/development/acceptance-app/ReactRefreshLogBox.test.ts: 335.878
test/integration/create-next-app/templates.test.ts: 334.01
test/integration/scss/test/group-2.test.js: 327.255
test/integration/scss/test/group-1.test.js: 318.574
test/integration/edge-runtime-configurable-guards/test/index.test.js: 313.834
test/e2e/instrumentation-hook/instrumentation-hook.test.ts: 294.618
test/development/acceptance-app/error-recovery.test.ts: 283.355
test/e2e/app-dir/app/vercel-speed-insights.test.ts: 278.242
test/integration/create-next-app/index.test.ts: 272.442
```
This adds new `build and test` and `build and deploy` workflows in favor
of the existing massive `build, test, and deploy` workflow. Since the
new workflows will use `pull_request_target` this waits to remove the
existing workflow until the new one is tested.
While testing this new workflow flakey behavior in tests have also been
addressed. Along with the new workflow we will also be leveraging new
runners which allow us to run tests against the production binary of
`next-swc` so this avoids slight differences in tests we've seen due to
running against the dev binary.
Furthermore we will have a new flow for allowing workflow runs on PRs
from external forks which will either require a comment be checking a
box approving the run after each change or a label added by the team.
The new flow also no longer relies on `actions/cache` or similar which
have proven to be pretty unreliable.
Tests runs with the new workflow can be seen here
https://github.com/vercel/next.js/actions/runs/5100673508/jobs/9169416949
<!-- 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 or adding/fixing 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
### Why?
### How?
Closes NEXT-
Fixes #
-->
### What?
WEB-1086.
This PR flips the way running next.js integration test with Turbopack,
instead of using allowlist to run selectively enabled test now uses
denylists. The immediate effect is now any new test being added (as a
new file) will be executed with Turbopack by default, and should be
manually excluded if it fails.
Still, the number of tests we run remains same.
<!-- 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 or adding/fixing 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 #
-->
This PR adjusts manifests for the next.js test with Turbopack, as I
found upstream test keep changing and need to sync its latests state
into the manifest.
Manifest is now .js file contains 2 arrays, one for the enabled, and
others for the disabled. Disabled doesn't mean it's always failing
though.
### What?
Disable `tracing/release_max_level_info` for non-published release
builds. I modified CI script to strip out logging for published
binaries.
### Why?
x-ref: https://vercel.slack.com/archives/C03EWR7LGEN/p1683621374204959
It's required to print logging for turbopack.
### How?
Closes WEB-1032
---------
Co-authored-by: Tobias Koppers <tobias.koppers@googlemail.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 or adding/fixing 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
### How?
Closes NEXT-
Fixes #
-->
### What?
This PR changes to the `root` of the cargo workspace to the root of repo
itself, allows next-swc and other rust codebase can use repo root as
workspace root.
### Why?
Currently cargo manifest for the next-swc is not placed under the root
of the repo, which makes invocation to the tool requires to change cwd /
or set cwd. Similarly needs to open editor to the root of the cargo
manifest separately to able to utilize language server kicks in. Moving
manifest to the root consolidates those, so can invoke either cli / or
editor to the same root of the repo.
### What?
* move some shared runtime logic to turbopack
* use relative imports from internal code when possible
* move react-refresh logic to turbopack
* move benchmark code logic to turobpack
see https://github.com/vercel/turbo/pull/4553
### Why?
We want to have benchmarking again for turbopack PRs
We want to have a standalone turbopack cli (eventually)
We want to avoid duplicating the runtime code
### How?
refactoring, moving code
### What?
enables the benchmark tests from turbopack again
### Why?
It tests common scenarios like HMR
fixes WEB-792
---------
Co-authored-by: Alex Kirszenberg <alex.kirszenberg@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 or adding/fixing 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 WEB-766.
This PR enables a new job for running tests, against turbopack. Since we
have observed some flakiness across turbopack test execution, it starts
from absolute minimum set of tests to not block any CI due to unexpected
failure.
Ran manual workflow roughly ~50 times and looks like these set of tests
are fine to make it as blocking check for the PR. In the future, depends
on the stability we'll increase number of test gradually.
### What?
Turbopack tests need to run on any change
### Why?
Next.js changes might break turbopack and we want to avoid that.
### How?
Change CI job
---------
Co-authored-by: kodiakhq[bot] <49736102+kodiakhq[bot]@users.noreply.github.com>
This re-enables running the CNA tests for all non-docs changes as it's now ensuring we don't regress on turbopack or our default templates.
Also fixes the main repo's package.json files from being modified during tests.
This ensures we only honor cache entries from the in memory cache for up
to 2 seconds so that revalidates can correctly propagate and also
increases max fetch cache entry size to 2 MB. The `fetchCache` export is
also being detected in this PR but not yet honored which will be done in
a follow-up.
As discussed this adds a publish workflow that can be triggered for
canary or stable releases which ensures we are publishing from a
consistent environment and local config doesn't affect a release.
This ensures the build spinner is correctly stopped in a TTY environment
and also adds regression tests for `app` and `pages` to ensure this
behaves as expected.
This updates our docker image to use the `jammy` tag instead of `focal`
to match the Ubuntu version to our CI.
### What?
A fork of https://github.com/github/issue-labeler that we pull in and
maintain.
### Why?
The official issue labeler had some issues which I tried to fix in PRs
and eventually got merged upstream, but the release cycle was a bit
slow, and that GitHub action had many parts we did not really need
anyway. So it makes sense to maintain it ourselves.
### How?
This PR removes the
https://github.com/vercel/next.js/blob/canary/.github/issue-labeler.yml
config file, which in our case is just a sublist of
https://github.com/vercel/next.js/labels anyway. Instead, we can pull in
the labels from GitHub directly and filter out those that we want to
apply to issues. This will keep things more in sync.
fix NEXT-750 ([link](https://linear.app/vercel/issue/NEXT-750))
---------
### What?
enables the next-dev-tests crate integration tests from trubopack
### Why?
to unblock the move PR we temporarily disabled the tests
### How?
Fix the new location and fix the expect dependency
Fixes WEB-708
---------
Co-authored-by: Justin Ridgewell <justin@ridgewell.name>
Update workspace cargo deps
Update cargo deps to point to local workspace
Ignore too-many-arguments warnings
Fix clippy errors
Update pnpm workspaces
exclude integration tests from unit tests CI
rust-analyzer settings
add rust flags and env vars
We want to make sure that our examples are not breaking.
We don't want to be slowed down by broken 3rd party packages, but we
need to ensure that examples covering next.js features are always green.
Added as a standalone workflow that doesn't parallelize. It will just
run on a cron schedule, so we can check for current status. We can add
Slack ping later if we need to.
The workflow tests just that our examples can build, so mostly TS
issues. We could definitely follow up with actual tests, but that is not
as low-hanging.
---------
Co-authored-by: kodiakhq[bot] <49736102+kodiakhq[bot]@users.noreply.github.com>
Co-authored-by: Tim Neutkens <tim@timneutkens.nl>
<!--
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:
-->
This PR updates the Edge Runtime docs on the next.js docs site with
simplified tables for each API section
## Bug
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Errors have a helpful link attached, see
[`contributing.md`](https://github.com/vercel/next.js/blob/canary/contributing.md)
## Feature
- [ ] Implements an existing feature request or RFC. Make sure the
feature request has been accepted for implementation before opening a
PR.
- [ ] Related issues linked using `fixes #number`
- [ ]
[e2e](https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs)
tests added
- [ ] Documentation added
- [ ] Telemetry added. In case of a feature if it's used or not.
- [ ] Errors have a helpful link attached, see
[`contributing.md`](https://github.com/vercel/next.js/blob/canary/contributing.md)
## Documentation / Examples
- [ ] Make sure the linting passes by running `pnpm build && pnpm lint`
- [ ] The "examples guidelines" are followed from [our contributing
doc](https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md)
---------
Co-authored-by: JJ Kasper <jj@jjsweb.site>
This updates our CI testing flow to only run against LTS Node.js version
on PRs and then run against the maintenance Node.js version when cutting
a release. This will allow speeding up PR test runs to get feedback
faster and remove un-necessary duplicate testing as it's very rare a
change breaks the maintenance Node.js version but not the LTS version.
This PR ensures the tests for codemods will automatically run in CI when the source code changes.
Co-authored-by: JJ Kasper <22380829+ijjk@users.noreply.github.com>
- reverted to github version because that works now
<!--
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:
-->
## Bug
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Errors have a helpful link attached, see
[`contributing.md`](https://github.com/vercel/next.js/blob/canary/contributing.md)
## Feature
- [ ] Implements an existing feature request or RFC. Make sure the
feature request has been accepted for implementation before opening a
PR.
- [ ] Related issues linked using `fixes #number`
- [ ]
[e2e](https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs)
tests added
- [ ] Documentation added
- [ ] Telemetry added. In case of a feature if it's used or not.
- [ ] Errors have a helpful link attached, see
[`contributing.md`](https://github.com/vercel/next.js/blob/canary/contributing.md)
## Documentation / Examples
- [ ] Make sure the linting passes by running `pnpm build && pnpm lint`
- [ ] The "examples guidelines" are followed from [our contributing
doc](https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md)
- [x] Depends on https://github.com/vercel/next.js/pull/45776
Turbotrace occupies too many memories while running; this PR makes it
run after the webpack build is finished, it can reduce the memory
hogging by webpack and turbotrace, thus avoiding OOM
The `maxFiles` option in turbotrace is removed because there is
`memoryLimit` option takes over its role.
Close WEB-556
Creates a new workflow and action that auto labels with `linear` whenever we apply `kind: bug`.
It's using JS action instead of docker, so it should be quite fast.
I tested this on my fork and it works.
Also created the action with TS so we can use it as a starting point for next actions so they can all be typed.
