ci: dogfood-msys job — spec22-gems acceptance against the fresh windows runtime (spec 22 C3) - #111
ci: dogfood-msys job — spec22-gems acceptance against the fresh windows runtime (spec 22 C3)#111ronaldtse wants to merge 7 commits into
Conversation
…sh windows runtime (spec 22 C3)
…broke validation)
f0d2ff6 to
fa3b886
Compare
…hidden scratch logs
Incident 13 round 4: the policy-denial verdicts (the EACCES classes the shim maps to error 5) journal to $TEBAKO_HOME/journal.log on the runner but the upload pattern only grabbed proof/install logs. Add the journal path; if-no-files-found already tolerates its absence on a clean run.
The closure-walk verdicts answer what the walk DID; the next forensic step is replaying the walk against the exact pressed bytes off-CI (the local repro loop). probe-gems-*.tfs ride the logs artifact — a few hundred KiB, retention unchanged.
Three build-speed fixes, one root cause each: 1. Roll cache key moves from the ruby-branch SHA (v1) to a hash of the rolled inputs (v2: versions.yml, patches, schema, tools). A probe commit touching only CI/harness files no longer mints a ~2.5 GB roll entry — the v1 key was evicting build prefixes under the 10 GB cap. 2. The link-unit job gains a staged-unit cache keyed on the tebako-rs and dwarfs-t input SHAs plus the link-unit scripts. A hit skips the whole compile stage; every builder/warmer/archive step is gated on the miss. The published pin still beats the cache. 3. harness_ref (workflow_call input, default main) points the dogfood acceptance-harness checkout at a tamatebako/ruby branch so a probe harness iterates UNMERGED; build-windows.yml passes it through. docs/build-chain.md gains THE SCOPE LAW: actions/cache is ref-scoped, so pull_request runs and branch dispatches never share entries (evidenced by runs 32204381083/32211646613 computing the identical prefix key e06b8398...-v4 and both missing). Iterate on ONE ref; a scope miss is never a CACHE_VER bump. spec/build_workflow_spec.rb pins the roll content key and the staged-unit guards (13/13 green).
|
Heads-up on the pull_request run this push just fired: its dogfood leg rides the acceptance harness at tamatebako/ruby@main, which is still the round-7 probe — the fiddle matrix leg dies under ruby 4.0 (fiddle left the default gems) and the sassc legs still fail (round-7's 126 predates the alias fix). That red is EXPECTED and is not a regression from this push. The live probe is the workflow_dispatch round 8 (run 32220821342), which rides this branch's workflow with harness_ref=ci/spec22-sassc-bisect-r8 (tamatebako/ruby#93). This push is the build-speed work: content-keyed roll cache (v2), staged link-unit cache with full miss-guards, and the harness_ref input the round-8 dispatch consumes. The gates stay as they are — the PR run's red dogfood is the harness being a round behind, by design, until the chain lands. |
What
Adds a
dogfoodjob to the windows_build-platform.ymllegs: after the full windows matrix completes, the job downloads this run's fresh 4.0.6 runtime package + msys devkit and runs the spec22-gems gem-level acceptance harness (tamatebako/ruby@main: ci/spec22-gems/run-msys.sh) against them.Spec 22 C3's last piece — the windows acceptance leg, executed in the only place it can run (a windows runner with same-run artifacts; the devkit artifact's 1-day retention is exactly why the leg lives factory-side).
The leg
TEBAKO_JAIL=deny;…:rwscratch grant), gemless (asserts notebako-runtimegemspec in the env image), on the last platform.mkmfagainst the devkit artifact from ci: upload an msys devkit artifact from windows build legs (spec 22 C3) #109 (stash headers + import lib) — no MSYS2 ruby involved; the ucrt64 toolchain is the same one the build legs use.tfs extractwith the published v0.1.9 windows tfs CLI + devkit overlay.materialize:negative-oracle probe pair andgem-loaded no) live in the harness README in tamatebako/ruby.Gating
inputs.platform == 'windows', skips audits, skips when aruby_filterdispatch excludes 4.0.6 (contains(needs.compute.outputs.ruby-matrix, '4.0.6')— bump both places when the dogfood line moves)..dogfood-scratch/proof-*.log+install.log(7d retention) for post-mortem.Proof plan
This PR's own CI run is the harness's first execution (no local windows dev box exists). Expected first-run failure classes and fixes are tracked in PROGRESS/07 (jail host-prefix spelling on windows, driver exec-cache placement vs the scratch grant, mkmf CC resolution via PATH, msys env quirks). Iteration happens on this branch until green.
Base
#109 (the devkit artifact this job consumes) is merged (
17d8d5e); this PR is one commit on main. (Supersedes draft #110, which GitHub closed un-reopenably when #109's branch was deleted — no content lost.)Test plan
dogfoodjob runs and reachesSPEC22-GEMS-MSYS-ACCEPTANCE-OK