Repository navigation
ci: faster CI and release runs, and the two flaky Auth tests - #191
Conversation
The build script watched console/dist/index.html, which is missing until the console is built. Cargo re-runs a build script on every build while a watched path is missing, so in such a checkout every `cargo build` recompiled console-front, suite-runtime and the CLI: about 43 s each time on a CI runner, in most steps of the Differential harness and of the client replays. It now watches the folder only (Cargo walks it), and dates a folder it creates to the script, so a fresh checkout builds once. A no-change build goes from 5.6 s to 0.15 s locally; adding, changing or removing a console file still re-embeds. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01GojiTpvSY8YywZFwh2ZJg2
The sign-in p99 test measures up to three rounds and passes on the first within both bounds; the p99 of 200 sign-ins is the third slowest, and a busy Intel macOS runner failed its ratio about one run in ten. A sign-in that waited for the encode still fails every round. Fixes #190. The persistence test flushes before it removes the state directory, so the writer thread cannot create a temporary file in it meanwhile ("Directory not empty"). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01GojiTpvSY8YywZFwh2ZJg2
The Intel macOS runner spent 18-25 minutes on the release build alone and 20-47 on the job, twice the next slowest platform, and it set the length of every packages and release run. The engine is now built for x86_64-apple-darwin on the Apple silicon runner (checked with lipo), and its release-mode tests, the npm and Bun installs and the suite smoke run the x86_64 engine with an x64 Node under Rosetta 2. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01GojiTpvSY8YywZFwh2ZJg2
The draft took the whole changelog, and the release owner cut it down to the version's section by hand. packaging/release-notes.mjs takes that section; on 0.2.3 it gives exactly the notes that were published. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01GojiTpvSY8YywZFwh2ZJg2
Under Rosetta, Bun's npm installer picks its Apple silicon build, which an x64 Node did not install, and fails. The x64 baseline build is installed directly (Rosetta offers no AVX), so Bun installs the darwin-x64 package as on an Intel Mac; the step checks that Bun reports x64. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01GojiTpvSY8YywZFwh2ZJg2
The journeys need the engine, not the console checks: the engine is built in a job of its own beside them, so the journeys start 2.5-4.5 minutes sooner. The six short journey projects (3-6 minutes each) run in pairs and the Functions journeys on Node 22 and 26 in one job, so a run asks for four fewer runners and waits less for them. Shell stays alone. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01GojiTpvSY8YywZFwh2ZJg2
The Functions, Cloud Tasks, Auth and Pub/Sub replays were the harness's longest steps, about 9 of its 19 minutes once the engine stopped rebuilding. They compare recorded answers and start no Java, so they run in a job of their own with their own ledger records and evidence. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01GojiTpvSY8YywZFwh2ZJg2
|
Before and after. Wall time is from the run's start to its last job. "Before" is the last five runs of each workflow on main or a code PR before this one.
A release runs CI and the packages together, as a pull request does, so its build phase before the approval should go from 34.8 min (0.2.2) and 35.4 (0.2.1) to about 18. For 0.2.3 that phase took 76.4 min, because #190 failed the first attempt. That figure is an estimate from this PR's runs; a release can't be dry-run. The darwin-x64 job on this PR ran on the Two failures here were not caused by this change. linux-x64's old-glibc step hit a Docker Hub |
Faster CI and release runs, and the two Auth tests that kept making a re-run necessary. Part of the 0.2.4 milestone.
What changes
cargo buildin a checkout without a console build.crates/console-front/build.rswatchedconsole/dist/index.html. Cargo re-runs a build script on every build while a watched path is missing, so console-front, suite-runtime and the CLI were recompiled each time: about 43 s on a CI runner, in most steps of the Differential harness and the client replays. Locally, a no-change build goes from 5.6 s to 0.15 s; adding, changing or removing a console file still re-embeds it.x86_64-apple-darwin(checked withlipo), and its release-mode tests, npm and Bun installs and suite smoke run the x86_64 engine with an x64 Node under Rosetta 2. The Intel runner took 20–47 min for this job, twice the next slowest platform, and set the length of every packages and release run.packaging/release-notes.mjs), not the whole changelog. On 0.2.3 it gives exactly the notes that were published.Checked locally: the Auth tests in release (82 passed, the two changed tests 5 more times each),
node --test packaging/*.test.mjs(195 passed),node packaging/check-release.mjs, the independence check, and the build script's rebuild behaviour in a fresh checkout, after a console build appears, after a nested asset changes and after it is removed.Before/after run timings follow in a comment once this PR's runs finish.
🤖 Generated with Claude Code
https://claude.ai/code/session_01GojiTpvSY8YywZFwh2ZJg2