From 9a1dda608fa2aafa73ceb5b3c2681365cec9dcfe Mon Sep 17 00:00:00 2001 From: Mykhailo Chalyi Date: Mon, 26 Oct 2026 11:26:12 +0000 Subject: [PATCH] fix(ci): retry the Rosetta cross build through toolchain segfaults The x86_64-apple-darwin lane added in #2780 is flaky, and because `js-check` gates on `callback-platforms` it blocks unrelated PRs: it failed that way on #2787, a GitHub Actions bump that touches none of this. Cross-linking to x86_64 on the arm64 runner intermittently dies with error: linking with `cc` failed: exit status: 1 clang: error: unable to execute command: Segmentation fault: 11 clang: error: linker command failed due to signal while linking a *build script*. Build scripts are host binaries, so no cross-compilation flag of ours is involved, and `crates/bashkit-js/.cargo/ config.toml` only sets rustflags for x86_64-pc-windows-msvc. It hit `libc` on one run and `getrandom` on another, roughly two runs in five, and recurred after the Rust cache was scoped per target in #2780 and again under a different `Swatinem/rust-cache` revision on #2787 -- so it is the toolchain crashing, not our cache or our configuration. Retry the cross build up to three times. cargo keeps whatever already compiled, so a retry resumes rather than rebuilds. This only absorbs the crash: a genuine compile error fails all three attempts and still fails the job, and the tests themselves are not retried, so the regression the lane was added to catch still fails it. --- .github/workflows/js.yml | 26 +++++++++++++++++++++++++- knowledge/runtimes/node-package.md | 7 +++++++ 2 files changed, 32 insertions(+), 1 deletion(-) diff --git a/.github/workflows/js.yml b/.github/workflows/js.yml index 37a3d1136..9d9251496 100644 --- a/.github/workflows/js.yml +++ b/.github/workflows/js.yml @@ -290,12 +290,36 @@ jobs: run: pnpm run build working-directory: crates/bashkit-js - if: ${{ matrix.target }} - run: pnpm exec napi build --platform --release --target ${{ matrix.target }} && pnpm run build:cjs && pnpm run build:ts + name: Build ${{ matrix.target }} working-directory: crates/bashkit-js + shell: bash env: # Match publish-js.yml, which is the other workflow building this # target. MACOSX_DEPLOYMENT_TARGET: "10.13" + run: | + # Cross-linking to x86_64 on the arm64 runner intermittently dies + # with `clang: error: unable to execute command: Segmentation + # fault: 11` while linking a *build script* -- the host-side binary, + # so nothing in this repo's flags is involved. It hit `libc` once and + # `getrandom` another time, roughly two runs in five, and because + # `js-check` gates on this job a crash of the toolchain would block + # unrelated PRs. cargo keeps whatever already compiled, so a retry + # resumes rather than rebuilds. Only the toolchain crash is retried: + # a genuine compile error fails again and still fails the job. + for attempt in 1 2 3; do + if pnpm exec napi build --platform --release --target ${{ matrix.target }}; then + break + fi + if [ "$attempt" = 3 ]; then + echo "cross build still failing after $attempt attempts" + exit 1 + fi + echo "::warning::cross build attempt $attempt failed; retrying" + sleep 15 + done + pnpm run build:cjs + pnpm run build:ts - run: pnpm exec ava __test__/runtime-functions.spec.ts working-directory: crates/bashkit-js - run: node --test __test__/runtime-compat/runtime-functions.test.mjs diff --git a/knowledge/runtimes/node-package.md b/knowledge/runtimes/node-package.md index 495e6697d..00e7efb45 100644 --- a/knowledge/runtimes/node-package.md +++ b/knowledge/runtimes/node-package.md @@ -60,6 +60,13 @@ the arm64 macOS runner. That is the slowest lane shipped; until v0.20.1 only `publish-js.yml` ran it, so a timing regression there first surfaced at release and blocked `release-js`, and with it both npm packages. +Cross-linking that target on the arm64 runner intermittently dies with +`clang: error: unable to execute command: Segmentation fault: 11` while linking +a build script -- a host-side binary, so no repo flag is involved. Observed on +`libc` and on `getrandom`, roughly two runs in five. The build step retries up +to three times; cargo keeps what already compiled, so a retry resumes. A real +compile error fails every attempt and still fails the job. + Cases that cancel a hanging host callback must budget an execution timeout covering interpreter start-up and scheduling latency before the callback is dispatched, not just the hang itself. Too small a budget expires first, the run