Same rationale as the Hetzner workflow change in 3168eff: headless Firefox
cannot create any GL context on the GPU-less runner.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Run 27330725978 died at container create: "range of CPUs is from 0.01 to
30.00, as there are only 30 CPUs available" with KICAD_DOCKER_CPUS=30 on the
30-vcpu standard-30. The Hetzner box (fresh docker-ce) accepts cpus == nproc;
Ubicloud's preinstalled daemon doesn't. A 29/30 CFS quota is noise.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Same recipe as ci-full-build.yml (all 6 tools, Binaryen 130 from source,
pipelined wasm-opt, KiCad e2e) but on ubicloud-standard-30: a plain runs-on
label, so no create/delete-Hetzner-VM jobs and no shared one-slot concurrency
lock. Push-triggered ONLY on this branch (plus workflow_dispatch) so it never
competes with the Hetzner main CI.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The xvfb/WebGL fix (f37ddc4) took CI from 22 to 11 failures (identical on
Hetzner 27343415331 and Ubicloud 27343416511) — everything left is the
pcbnew family, still dying at wasm compile: pcbnew's ~190M debug module
exceeds SpiderMonkey's per-process code budget on x86-64 even with the
baseline-only JIT (the same module compiles on arm64, whose denser code
fits — which is why the local arm64 repro passed). No pref raises that
limit; V8 handles the module fine.
New CI-only 'chromium-ci' project (bundled Chromium, headless, SwiftShader
via --enable-unsafe-swiftshader) carries pcbnew/pcbnew-collab/load-pcb/
load-pcb-probe; the firefox project ignores them on CI. Workflows call the
new test:kicad:ci script which runs both projects. Local test:kicad is
unchanged (firefox everywhere, system Chrome for headed runs).
Validated under x86 emulation (linux/amd64 playwright image on Rosetta):
the pcbnew wizard test passes on chromium-ci in 23s against the fresh
v130-postprocessed 192M module.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
CI runs (Hetzner 27329612719, Ubicloud 27330989479) failed 22/41 identically,
in two buckets, both firefox-environment issues (the suite is firefox-only:
test:kicad -> --project=firefox):
1. No WebGL: headless Firefox can't create ANY GL context on a GPU-less VM
(blocklist bypass still dies with FEATURE_FAILURE_WEBGL_EXHAUSTED_DRIVERS),
so the GAL canvas failed and an error dialog blocked every UI flow. Fix:
run headed under xvfb (GLX + Mesa llvmpipe software GL) with
webgl.force-enabled — workflows now wrap the e2e step in xvfb-run.
2. pcbnew wasm OOM: the ~190M module OOMs Firefox's optimizing wasm JIT at
compile ("InternalError: out of memory") and the app never boots. Fix:
javascript.options.wasm_optimizingjit=false (baseline-only compile).
Both prefs are CI-gated in playwright-kicad.config.ts; local runs keep stock
behavior. Boot got slower (baseline JIT), so the wizard helpers now wait for
the registry to have actual UI ENTRIES (the registry OBJECT exists pre-boot)
instead of clicking into a fixed 10x500ms window.
Validated in a local docker repro of the CI env (playwright:v1.57.0 image,
no GPU): pl_editor canvas, gerbview wizard+canvas, and pcbnew wizard (on a
properly asyncified 187M module) all pass; before the fix they reproduced the
exact CI signatures.
Known-fail left on CI: zoom-cursor — the zoom-in anchors at ~ -P in headed
Firefox (screen-vs-client coordinate mix-up in the wheel->GAL path, headed
mode only); marked test.fixme(CI) pending a wx-wasm-layer investigation.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Per run, a fresh ccx53 VM is created (Cyclenerd/hcloud-github-runner),
builds + tests run on it, and it is always torn down — no persistent
infra, no lingering cost. Secrets: HCLOUD_TOKEN, HETZNER_RUNNER_PAT.
- ci-full-build.yml: the main-branch CI and the only push-triggered
workflow. Full build of all 6 tools (pipelined wasm-opt, self-built
Binaryen 130, ~1h15m) + KiCad e2e; docs-only pushes excluded via
paths-ignore.
- ci.yml (eeschema-only smoke) and wasm-opt-bench.yml (config sweeps):
workflow_dispatch-only, since every push-run costs a paid VM.
- Shared one-Hetzner-slot concurrency group across the workflows.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
