We either need GCC >= 4.9 or we need to link with libatomic:
https://github.com/microsoft/mimalloc/issues/443
Unfortunately, manylinux2014-cross ships with GCC 4.8.5:
https://github.com/rust-cross/manylinux-cross/blob/main/manylinux2014/aarch64/Dockerfile#L71
We already appear to override the compiler toolchain in CI for x86_64 to
use clang (which is why mimalloc works there), so let's go ahead and do
that here too. This at least means we're using the same compiler across
both architectures.
I'm leaving the aarch64-musl codepath the same (using gcc) because (1)
we don't use mimalloc there yet and (2) it's a bit harder for me to test
as thoroughly.
# Testing
## Local Compilation
Run bash inside the docker image (I also had to install rosetta2 inside
my Linux VM, as this is an x86_64 image used for cross-compilation to
aarch64):
```
podman run --platform=linux/amd64 -t -i ghcr.io/napi-rs/napi-rs/nodejs-rust:stable-2023-09-17-aarch64 bash -l
```
```
git clone https://github.com/vercel/next.js.git --filter=blob:none --branch canary --single-branch
cd next.js
git checkout 6ae9828cce
```
Run the build locally:
```
apt update &&
apt install -y pkg-config xz-utils dav1d libdav1d-dev &&
export JEMALLOC_SYS_WITH_LG_PAGE=16 &&
rustup show &&
rustup target add aarch64-unknown-linux-gnu &&
npm i -g "@napi-rs/cli@${NAPI_CLI_VERSION}" &&
export CC_aarch64_unknown_linux_gnu=/usr/bin/clang &&
export CFLAGS_aarch64_unknown_linux_gnu="--target=aarch64-unknown-linux-gnu --sysroot=/usr/aarch64-unknown-linux-gnu" &&
cd packages/next-swc && npm run build-native-release -- --target aarch64-unknown-linux-gnu &&
llvm-strip -x native/next-swc.*.node &&
objdump -T native/next-swc.*.node | grep GLIBC_
```
Sanity check that the result is an aarch64 binary
```
$ file native/next-swc.linux-arm64-gnu.node
native/next-swc.linux-arm64-gnu.node: ELF 64-bit LSB shared object, ARM aarch64, version 1 (SYSV), dynamically linked, not stripped
```
## Verifying the binary works
Copy the next-swc binary into a copy of shadcn-ui I have sitting around:
```
podman cp 4e8f61b17965:/next.js/packages/next-swc/native/next-swc.linux-arm64-gnu.node ~/ui/node_modules/.pnpm/file+..+nextpack+tarballs+next-swc.tar/node_modules/@next/swc/native/next-swc.linux-arm64-gnu.node
```
and then try running the dev server and loading pages from it in the
browser:
```
pnpm --filter=www dev --turbo
```
## In CI
https://github.com/vercel/next.js/actions/runs/9523143080/job/26254016137
- remove fail fast so we can get a full picture of what's failing
- remove alerting/retrying to existing job
---------
Co-authored-by: JJ Kasper <jj@jjsweb.site>
This disables tests that should not be run in a deployed environment,
because they use incompatible APIs or there's no reason to test them
outside of `next start`. Specifically disables for things like:
- Using `next.patchFile`, `next.renameFile`, etc.
- Attempting to use `next.cliOutput` to query runtime logs. When
deployed, these are only build-time logs.
[Latest Run](https://github.com/vercel/next.js/actions/runs/9483807368)
[Test
Run](https://github.com/vercel/next.js/actions/runs/9471783416/job/26095882422)
Changes:
- Add a setup step that clears the project so it doesn't happen in each
runner
- Run when a release is published rather than on cron
- Notify via Slack when a failure occurs
- Leverage build_reusable for the test runner to match the
build_and_test workflow
- Fixes to `next-deploy` script: not properly logging/catching errors
- Adds manifest to ignore known issues
- Split into 6 runners with 2 concurrency (12 deploys at a time)
- Adds some logging so we know what's happening
- Disable Playwright trace mode (it kept failing to find a trace file
and cluttering the output. Don't think we need it here anyway)
<details>
- <summary>Removed noisy output</summary>
</details>
<!-- 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 #
-->
I'm working on fixing our deploy tests workflow. See:
- #66721
This particular workflow runs on each PR but it uses the canary version.
It also wipes the deploy test project which will cause conflicts with
the main e2e one.
Removing this for now since it's not working as intended, and will
reland it with fixes.
<!-- 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 #
-->
### What?
* [allow to re-run the action that publishes the
release](ce4f629d73)
* [allow to force trigger a new
release](7e26cd7794)
### Why?
On failure we might want to re-run the whole action or publish a new
release without changes
As noted in (https://github.com/vercel/nextpack/pull/103), by not having
this as a default feature, when running the `build-native` script it's
not able to re-use any cargo caches that might already exist from a
default build.
Because this feature impacts the swc crate, everything dependent on it
can be forced to rebuild.
By making this a default feature, the hope/theory is that the number of
different ways we potentially build our dependency graph reduces, and
cargo cache hits will improve.
## Changes
- Add `plugin` to the default set of features for `next-swc-napi`.
- Consolidate `build-native-no-plugin-woa` with
`build-native-no-plugin`. Given the lack of any other default features,
these are equivalent.
- `i686-pc-windows-msvc`: Switch to `build-native-no-plugin-release` in
CI instead of just supplying the `--release` flag. This has the benefit
of also enabling `tracing/release_max_level_info`, which might reduce
the size of or speed up these builds.
- `x86_64-apple-darwin`: Remove a redundant `--release` flag in the CI
config (no expected changes).
## Testing
I've tested this locally on Linux (`pnpm run build-native`) and
Windows-on-ARM (`pnpm run build-native-no-plugin`) by making sure things
still build. I'll also make sure CI passes.
