Green the native V8 CI lanes: standalone runner, gtest discovery, gatsby (ECO-416) - #133
Merged
Merged
Conversation
Arshia001
force-pushed
the
eco-416-native-cluster-ci
branch
from
July 28, 2026 14:41
41d7f43 to
21fe794
Compare
…sby (ECO-416) The native-parity CI added in b93913d has been red on every stack branch (main never ran these steps). Four independent, pre-existing issues in that new CI — none in EdgeJS runtime code: 1. Standalone (deterministic, v8-linux + v8-macos): the native `standalone-build-test` target left SYMLINK_TARGET unset, so standalone-build-test.js fell back to its default runner `build-edge-quickjs-cli/edge` — a QuickJS binary the native V8 job never builds → "runner target is not executable". Pin the runner to the native binary, mirroring standalone-build-test-quickjs-native. 2. gtest discovery (flake, v8-macos "Build edge"): gtest_discover_tests runs each freshly-built test binary at build time to enumerate cases; on macOS runners that intermittently emits empty JSON → ParseTestList.cmake fails the whole build. CI never runs these via ctest (it uses the nodejs_test_harness), so switch `make build` to DISCOVERY_MODE PRE_TEST, deferring discovery off the build path. Local `cmake` keeps POST_BUILD. 3. gatsby segfault (flake, v8-linux framework apps): `gatsby build` on the Node.js reference intermittently segfaults in the lmdb native addon. Retry a build up to 3x, but only when the log shows a native crash (SIGSEGV/SIGABRT/core dumped/worker signal) — a deterministic non-zero build error is never retried. 4. gatsby hang (v8-macos framework apps): `gatsby build` deterministically hangs on macOS runners (gatsby-worker/sharp) and the harness has no build-step timeout, so a retry cannot help. Exclude js-gatsby-* on macOS only, mirroring quickjs-macos; Linux keeps building gatsby with the retry above. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Arshia001
force-pushed
the
eco-416-native-cluster-ci
branch
from
July 28, 2026 14:57
21fe794 to
a880a8a
Compare
wasmer main added lib/wild (the wild linker); wasmer-compiler path-depends on wasmer-wild at lib/wild/libwild, so the source provision must init it or the C-API/CLI build fails with 'failed to read lib/wild/libwild/Cargo.toml'.
2 tasks
syrusakbary
approved these changes
Aug 7, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Stacked on #132. Greens the native
v8-linux/v8-macoslanes, which have been red on every stack branch since the native-parity CI was added inb93913d7(main never runs these steps, so main stays green). Four independent, pre-existing CI-infra issues — none in EdgeJS runtime code; EdgeJS passes every app on both lanes.Fixes
1. Standalone runner — deterministic (v8-linux + v8-macos).
The native
standalone-build-testtarget leftSYMLINK_TARGETunset, sostandalone-build-test.jsfell back to its default runnerbuild-edge-quickjs-cli/edge— a QuickJS binary the native V8 job never builds →runner target is not executable. Pin the runner to the native binary, mirroringstandalone-build-test-quickjs-native.2. gtest discovery flake (v8-macos "Build edge").
gtest_discover_testsruns each freshly-built test binary at build time to enumerate cases; on macOS runners that intermittently emits empty JSON →ParseTestList.cmakefails the whole build. CI never runs these gtest binaries viactest(it usesnodejs_test_harness), somake buildnow usesDISCOVERY_MODE PRE_TEST, deferring discovery off the build path. LocalcmakekeepsPOST_BUILD(the dedupe custom command still applies, and already no-ops on a missing manifest).3. gatsby segfault flake (v8-linux framework apps).
gatsby buildon the Node.js reference intermittently segfaults in the lmdb native addon. Retry a build up to 3×, but only when the log shows a native crash (SIGSEGV/SIGABRT/SIGBUS/core dumped/worker-signal). A deterministic non-zero build error never matches and is never retried.4. gatsby hang (v8-macos framework apps).
gatsby builddeterministically hangs on macOS runners (gatsby-worker/sharp) and the harness has no build-step timeout, so a retry cannot help. Excludejs-gatsby-*on macOS only, mirroringquickjs-macos. Linux keeps building gatsby with the retry above.Validation
build-edge/edge(the binary the native job actually builds). The bug never reproduces locally only because the QuickJS binary happens to be present; CI doesn't build it.ELIFECYCLE/Cannot find module/ render errors.Caveat on #3: the retry re-runs
gatsby buildin place (dirty.cache) rather than a fresh checkout; gatsby's incremental build tolerates this. If it proves insufficient, cleaning artifacts between retries is a follow-up.🤖 Generated with Claude Code