GitHub Actions caches are branch-scoped: a fixture cache written by a PR's CI is invisible to main. So every fixture-changing merge currently costs one redundant rebuild — the merge commit's Sphinx run cache-misses and rebuilds the fixture (~15 min of runner time), producing a fixture that is immediately superseded by the deliberate post-merge refresh (whose artifact is what baselines are regenerated against).
Observed on the PR #9 merge: the PR built+cached the fixture on its branch scope, then main's Sphinx run rebuilt it from scratch anyway, then the refresh workflow rebuilt it a third time as the canonical copy.
Options, roughly in order of appeal:
- Seed from the merged PR's artifact. A workflow_run-triggered job (or a step in the refresh workflow) that downloads the merged PR's
sienna-v4-fixture artifact and writes it to main's cache under the same key — no rebuild at all, and baselines stay consistent with what the PR actually tested against. Wrinkle: artifact retention (7 days) and locating the right run from the merge commit.
- Make Sphinx defer instead of rebuild. When the fixture cache is cold, skip the gallery build (docs deploy without gallery or don't deploy) and let the post-refresh rebuild produce the full docs. Wrinkle: docs lag the merge until someone runs the refresh.
- Auto-trigger the refresh on fixture-changing merges (workflow_run / push-path filter) so at least the redundant build and the canonical build collapse into one deliberate sequence. Wrinkle: reintroduces an automatic rebuild path, which the fail-fast design deliberately avoids — would need the baseline-regen step to stay human.
Context: the fail-fast design in tests.yml exists because implicit rebuild-on-miss caused silent fixture/baseline drift (see the workflow comments). Any change here must preserve the invariant that the cached fixture and committed baselines always come from the same build.
Fixture-changing merges are rare (next candidates: #10 stressed fixture, #13 horizon change), so this is efficiency polish, not urgency.
GitHub Actions caches are branch-scoped: a fixture cache written by a PR's CI is invisible to main. So every fixture-changing merge currently costs one redundant rebuild — the merge commit's Sphinx run cache-misses and rebuilds the fixture (~15 min of runner time), producing a fixture that is immediately superseded by the deliberate post-merge refresh (whose artifact is what baselines are regenerated against).
Observed on the PR #9 merge: the PR built+cached the fixture on its branch scope, then main's Sphinx run rebuilt it from scratch anyway, then the refresh workflow rebuilt it a third time as the canonical copy.
Options, roughly in order of appeal:
sienna-v4-fixtureartifact and writes it to main's cache under the same key — no rebuild at all, and baselines stay consistent with what the PR actually tested against. Wrinkle: artifact retention (7 days) and locating the right run from the merge commit.Context: the fail-fast design in tests.yml exists because implicit rebuild-on-miss caused silent fixture/baseline drift (see the workflow comments). Any change here must preserve the invariant that the cached fixture and committed baselines always come from the same build.
Fixture-changing merges are rare (next candidates: #10 stressed fixture, #13 horizon change), so this is efficiency polish, not urgency.