feat(ci): a cache input, because a persistent depot pays for the cache twice (#62) - #71
Merged
Merged
Conversation
…che twice (#62) `julia-actions/cache@v3` ran in both jobs with no guard and no way to turn it off, while this workflow's own default runner is `'["self-hosted","rosina"]'` — a pool whose Julia depot already persists per box, and per runner since the depot-front change. There the restore is a no-op and the SAVE is not. MEASURED, from #62. One green eight-shard run (FunctionMeasures.jl 30826019824): 44–182 s of post-step per shard against 58–268 s of actual testing, ≈620 s of runner time per run for a depot that was already on the box. The single shared key makes it worse rather than better here — all N shards finish together and then all upload the same large depot, N−1 of them pointlessly even when they succeed. And when it does not merely cost, it hangs. Three jobs on 2026-08-03 whose `Run shard` step SUCCEEDED went red or never finished in that post-step, one holding a runner for 114 minutes. The failure shape is the bad one: tests pass, job red, and nothing in `gh pr checks` tells that apart from a real failure without opening the step list. A hung post-step also holds a self-hosted runner indefinitely, so it shrinks the pool for everyone and reads downstream as ordinary queueing. Seen again today on ParaLinearAlgebra.jl 30961107784: six shards on `rosina` spent 4–5 minutes EACH in the post-step and finished; the two on `panza` were still in it 16 minutes later with every test green. `cache` defaults to `true`, so a hosted caller is unaffected — it is the caller that knows whether its depot survives the job. The org-wide reusable, whose default runner is the self-hosted pool, sets it false in the companion PR.
Contributor
|
📚 Docs preview: https://codes.sota-shimozono.com/TestShards.jl/previews/PR71/ (updates on each push to this PR) |
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #62.
julia-actions/cache@v3ran in both jobs with noif:and no input to turn it off, while thisworkflow's own default runner is
'["self-hosted","rosina"]'— a pool whose Julia depot alreadypersists per box. There the restore is a no-op and the save is not.
The cost, when it works
From #62, one green eight-shard run (FunctionMeasures.jl 30826019824): 44–182 s of post-step per
shard against 58–268 s of actual testing — ≈620 s of runner time per run, for a depot that was
already on the box. The single shared key (
cache-name: testshards,include-matrix: 'false') isright for the hosted case and makes this worse: all N shards finish together and then all upload the
same large depot, N−1 of them pointlessly even when they succeed.
The cost, when it does not
Three jobs on 2026-08-03 whose
Run shardstep succeeded went red or never finished in thatpost-step — one holding a runner for 114 minutes. The failure shape is the bad one: tests pass,
job red, and
gh pr checkscannot tell it from a real failure without opening the step list. A hungpost-step also holds a self-hosted runner indefinitely, so it shrinks the pool for everyone and reads
downstream as ordinary queueing.
Seen again today, ParaLinearAlgebra.jl run 30961107784, while this was being written:
Post Run julia-actions/cache@v3rosina-org-*panza-3,panza-4The change
A
cacheinput,if: ${{ inputs.cache }}on both steps, defaulting totrueso a hosted calleris unaffected — the caller is what knows whether its depot survives the job. The companion PR sets it
falseinlab-sotashimozono/.github, whose default runner is the self-hosted pool.Prior art the issue records: ParaLinearAlgebra.jl explicitly dropped
julia-actions/cachewhen itsmatrix moved to rosina (its PR #96, "dropped
julia-actions/cache= persistent depot"), and adoptingTestShards re-introduced it to every repo that migrated.