fix(release): build the Linux x64 Node addon against glibc 2.17 (#1670) - #1678
Conversation
The x64 addon was built natively on the Ubuntu 24.04 runner and required glibc 2.39. Build it with the napi cross toolchain (glibc 2.17) like the aarch64 addon, on a Node 22 build host, then execute it on the Node 20 engines floor. A fail-closed step reads the highest GLIBC_ version from each Linux addon and refuses anything above the declared 2.17 floor. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
|
Important Review skippedAuto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Repository: CurateLabs/graphforge/.coderabbit.yaml Review profile: CHILL Plan: Advanced Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
Warning Billing warning: we have not been able to collect payment for this subscription for more than 72 hours. Please update the payment method or pay any pending invoices in Billing to avoid service interruption. Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Closes #1670.
What
.github/workflows/binding-release-candidate.yml:--use-napi-cross, the prebuilt gcc toolchain that links against glibc 2.17, as the aarch64 lane already does. That toolchain's unpacker (@napi-rs/lzma) needs Node ≥ 22, so the lane builds onnode_version: "22". It then switches back with a secondactions/setup-nodestep toruntime_node_version: "20", theengines.nodefloor, and checks the major version before the native smoke and parity contract runs. The executing lane therefore still proves Node 20.glibc_floor, which covers both*-unknown-linux-gnulanes. It reads the addon's highestGLIBC_version withreadelf --dyn-syms --wide, which works on any ELF architecture and so also checks the cross-built aarch64 addon on the x64 host. It refuses anything above 2.17, and runs before the addon is executed.scripts/ci/test-binding-release-candidate.py: the assertion "only the ARM lane pins a Node version" described the old layout, not a requirement. It now checks the property itself:--use-napi-crosslane pins a Node ≥ 22 build host;runtime_node_versionappears only on native lanes that pin a build Node;glibc_floor: "2.17", and no other lane declares one;readelf, runs underset -euo pipefail, contains no||, exits 1 on violation, and comes before the native contract.Evidence
pnpm --filter @curatelabs/graphforge exec napi build --platform --release --target x86_64-unknown-linux-gnu --use-napi-cross, Node 22.22.1, napi CLI 3.10.4):version()returns0.5.2;test:smokepassed 8/8, andnon-cypher-release-parity+async-errors+export-surfacepassed 9/9.glibc_required=2.16 floor=2.17, exit 0;graphforge.linux-x64-gnu.node), "needs glibc 2.39, above the declared floor 2.17", exit 1.test-binding-release-candidate.py:runtime_node_version;glibc_floor;true ||;set -euo pipefailfrom the floor step.python3 scripts/ci/test-binding-release-candidate.py,test-ci-storage-policy.py,workflow_policy.py,scripts/check-workflows.sh(actionlint) andmake pre-push-fastall pass.ruff formatandruff checkare clean.Only provable after merge
Binding RC only runs on the current
mainSHA, so acceptance criterion 1 needs a dispatch on the merge commit: a Binding RC run whose Linux x64 addon is ≤ 2.17 and passes the lane's native contract on Node 20. I'll dispatch it after merge and post the result on #1670.🤖 Generated with Claude Code
Need help on this PR? Tag
@codesmith-botwith what you need. Autofix is disabled.