Skip to content

ci: dogfood-msys job — spec22-gems acceptance against the fresh windows runtime (spec 22 C3) - #111

Draft
ronaldtse wants to merge 7 commits into
mainfrom
feat/msys-dogfood-job
Draft

ci: dogfood-msys job — spec22-gems acceptance against the fresh windows runtime (spec 22 C3)#111
ronaldtse wants to merge 7 commits into
mainfrom
feat/msys-dogfood-job

Conversation

@ronaldtse

@ronaldtse ronaldtse commented Aug 17, 2026

Copy link
Copy Markdown
Contributor

What

Adds a dogfood job to the windows _build-platform.yml legs: 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

  • Real sinatra + sassc, jailed (TEBAKO_JAIL=deny;…:rw scratch grant), gemless (asserts no tebako-runtime gemspec in the env image), on the last platform.
  • Native-extension compile (sassc) goes through the fresh runtime's OWN mkmf against 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.
  • The bridge (mount-root reconstitution) is tfs extract with the published v0.1.9 windows tfs CLI + devkit overlay.
  • Leg matrix and pinned verdicts (incl. the materialize: negative-oracle probe pair and gem-loaded no) live in the harness README in tamatebako/ruby.

Gating

  • inputs.platform == 'windows', skips audits, skips when a ruby_filter dispatch excludes 4.0.6 (contains(needs.compute.outputs.ruby-matrix, '4.0.6') — bump both places when the dogfood line moves).
  • Always uploads .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

  • windows matrix green (unchanged — additive job)
  • dogfood job runs and reaches SPEC22-GEMS-MSYS-ACCEPTANCE-OK

@ronaldtse
ronaldtse force-pushed the feat/msys-dogfood-job branch from f0d2ff6 to fa3b886 Compare August 17, 2026 12:48
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).
@ronaldtse

Copy link
Copy Markdown
Contributor Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants