ci: Docker build crashes with illegal instruction under arm64 emulation

[mtrezza]

Pull Request

• Report security issues confidentially.
• Any contribution is under this license.

Issue

The Docker image build crashes in about 1 of 10 runs with qemu: uncaught target signal 4 (Illegal instruction), when Node.js runs under QEMU emulation to build the arm64 image. The crash only occurs on runners with an AVX-512 CPU. It fails the Docker Build check, which is required on beta, release and release-8.x.x, and the Docker release job, which then publishes no image; for example 9.10.1 was missing on Docker Hub until it was published manually.

Closes #10705, part of #10681.

Approach

The image is cross-built, so that no code runs under emulation and QEMU is not needed anymore.

• The build stage runs on the platform of the build machine (FROM --platform=$BUILDPLATFORM). It installs the production dependencies for the architecture of the image with npm ci --os=linux --cpu=<arch> --libc=musl. Only @node-rs/bcrypt has platform-specific production dependencies, and install scripts were already skipped with --ignore-scripts. The build output in lib/ does not depend on the platform.
• The release stage has no RUN instruction anymore; a comment says it must not have one. The logs folder owned by node is created by copying an empty folder from the build stage with COPY --chown=node:node.
• Builders that don't set BUILDPLATFORM and TARGETARCH, like the legacy Docker builder and kaniko, run the build stage on their own platform and install the dependencies for it, as before.
• The workflows do not set up QEMU anymore. If release-manual-docker.yml builds a ref with a previous Dockerfile, BuildKit falls back to its own bundled QEMU. The missing images of stable v9 releases were already published with the previous workflow. Note that BuildKit would also run a RUN instruction added to the release stage under its bundled QEMU instead of failing.
• The job name Docker Build is unchanged, so the required checks need no change.

Native arm64 runners were considered as well. They also avoid emulation, but require one job per platform, a job in each release workflow that merges the pushed images into a multi-platform image, and a job that reports the required Docker Build check. Pinning a QEMU version was rejected, because the crash already occurred months before the current QEMU version became the default.

Verified locally on an arm64 host with Docker 29.5.3, comparing images built with the previous and the new Dockerfile:

• A multi-platform build as in CI runs no command for the emulated platform with the new Dockerfile, compared with 3 commands with the previous Dockerfile.
• For linux/amd64 and linux/arm64, the /parse-server folder of both images is identical in content, file mode and owner, and so is the image configuration.
• Both new images start with MongoDB and pass a health check, object save, sign-up and log-in. The native @node-rs/bcrypt binding loads for the architecture of the image, and the server writes log files as user node.
• The legacy Docker builder (Docker 24, DOCKER_BUILDKIT=0) and kaniko 1.23.2 build an image with the same /parse-server folder as BuildKit. A linux/arm/v7 image builds and runs.

Tasks

• Add tests
• Add changes to documentation (guides, repository pages, code comments)
• Add security check
• Add new Parse Error codes to Parse JS SDK

Summary by CodeRabbit

• Builds & Releases
  • Docker images continue to target amd64 and arm64, with build steps configured to support cross-platform image builds.
  • Production dependencies are selected for the image’s target architecture. Builds report an error when the architecture is unsupported.
  • The release image receives its logs directory from the build stage, keeping image creation consistent across target platforms.

[parse-github-assistant]

🚀 Thanks for opening this pull request! We appreciate your effort in improving the project. Please let us know once your pull request is ready for review.

Tip

• Keep pull requests small. Large PRs will be rejected. Break complex features into smaller, incremental PRs.
• Use Test Driven Development. Write failing tests before implementing functionality. Ensure tests pass.
• Group code into logical blocks. Add a short comment before each block to explain its purpose.
• We offer conceptual guidance. Coding is up to you. PRs must be merge-ready for human review.
• Our review focuses on concept, not quality. PRs with code issues will be rejected. Use an AI agent.
• Human review time is precious. Avoid review ping-pong. Inspect and test your AI-generated code.

Note

Please respond to review comments from AI agents just like you would to comments from a human reviewer. Let the reviewer resolve their own comments, unless they have reviewed and accepted your commit, or agreed with your explanation for why the feedback was incorrect.

Caution

Pull requests must be written using an AI agent with human supervision. Pull requests written entirely by a human will likely be rejected, because of lower code quality, higher review effort and the higher risk of introducing bugs. Please note that AI review comments on this pull request alone do not satisfy this requirement. Our CI and AI review are safeguards, not development tools. If many issues are flagged, rethink your development approach. Invest more effort in planning and design rather than using review cycles to fix low-quality code.

[coderabbitai]

Navigate logical layers of code changes, visualize relationships, and explore their blast radius.

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Essentials

Run ID: 1a800364-1b86-4040-ba0c-7ff0c7979e5e

📥 Commits

Reviewing files that changed from the base of the PR and between 34bb458 and 4aa4173.

📒 Files selected for processing (1)

• .github/workflows/release-manual-docker.yml

💤 Files with no reviewable changes (1)

• .github/workflows/release-manual-docker.yml

Included review availability: This review used your included allowance. Your plan provides up to 10 included reviews per hour; 9 remain after this review.

---

📝 Walkthrough

Walkthrough

The Docker build stage now runs on the build platform and selects production dependencies for the target architecture. The release stage copies /logs from the build stage. The CI and release workflows no longer set up QEMU.

Changes

Docker build flow

Layer / File(s)	Summary
Build and release stages Dockerfile	The build stage runs on the build platform, selects production dependencies based on TARGETARCH (or the builder architecture when unset), installs dependencies, builds the application, and creates /logs. The release stage copies /logs from the build stage.
Workflow QEMU setup changes .github/workflows/ci.yml, .github/workflows/release-automated.yml, .github/workflows/release-manual-docker.yml	The CI, automated release, and manual Docker release workflows no longer set up QEMU. The configured Docker build platforms remain linux/amd64 and linux/arm64/v8 where specified.

Priority: ⬆️ High

Estimated code review effort: 3 (Moderate) | ~20 minutes

Severity of issue fixed: Medium

Sequence Diagram(s)

sequenceDiagram
  participant Workflow
  participant Buildx
  participant BuildStage
  participant npm
  participant ReleaseStage
  Workflow->>Buildx: Build for linux/amd64 and linux/arm64/v8
  Buildx->>BuildStage: Run build stage on the build platform
  BuildStage->>npm: Install production dependencies for TARGETARCH
  BuildStage->>npm: Install dependencies and build
  BuildStage->>ReleaseStage: Copy /logs

Loading

Merge Risk: ⚪ Minimal · up to 4aa41

The changed Docker builds have no established merge-blocking issue after the platform and legacy-builder paths were checked.

🚥 Pre-merge checks | ✅ 6 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Out of Scope Changes check	⚠️ Warning	The manual Docker release workflow removes its QEMU setup step. The stated PR scope says that workflow retains QEMU to support builds with earlier Dockerfiles. The removal changes legacy Dockerfile su…	Restore the QEMU setup step in .github/workflows/release-manual-docker.yml, unless the PR scope and compatibility requirements are explicitly changed.

✅ Passed checks (6 passed)

Check name	Status	Explanation
Linked Issues check	✅ Passed	The PR satisfies the coding objective in [#10705]. Dockerfile runs the build stage on BUILDPLATFORM, selects target architecture dependencies with TARGETARCH, and removes RUN instructions from…
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check. Docstring coverage is scoped to functions touched by this diff. Analyzed 0 functions across 0…
Security Check	✅ Passed	PASS: The pull request changes only Docker build architecture handling and removes QEMU setup steps. The new TARGETARCH mapping is allowlisted before use, and the release image still runs as the non…
Engage In Review Feedback	✅ Passed	The current review produced zero actionable findings, and no CodeRabbit review threads were returned. Therefore, no review feedback required engagement, implementation, or discussion.
Title check	✅ Passed	The title begins with the required ci: prefix, uses a capitalized first word, and clearly describes the Docker build failure addressed by the changes.
Description check	✅ Passed	The description includes all required sections. It explains the issue, approach, validation, and task status with relevant technical detail.

Full details: Out of Scope Changes check

Explanation

The manual Docker release workflow removes its QEMU setup step. The stated PR scope says that workflow retains QEMU to support builds with earlier Dockerfiles. The removal changes legacy Dockerfile support and is not required to fix the CI or automated release failures in [#10705].

• Fix all pre-merge checks with AI

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create a new PR

---

_{Comment @coderabbitai help to get the list of available commands.}

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 93.86%. Comparing base (2de0ab2) to head (4aa4173).

Additional details and impacted files

@@            Coverage Diff             @@
##            alpha   #10706      +/-   ##
==========================================
- Coverage   93.88%   93.86%   -0.02%     
==========================================
  Files         193      193              
  Lines       17061    17061              
  Branches      257      257              
==========================================
- Hits        16017    16015       -2     
- Misses       1022     1024       +2     
  Partials       22       22              

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.