fix(ci): three uploads ignored the input that already gates their consumer — so an artifact-free run is now actually artifact-free (#78)

[sotashimozono]

Closes part of #78.

What is wrong

Every upload in sharded-tests.yml is continue-on-error: true after #76/#77, so a full artifact quota no longer turns a green suite red. What it still does is attempt six uploads per run — and on an account at its quota that is six failed API calls and a log full of errors nobody can act on.

Three of the six are produced for consumers that can be switched off, and the inputs that switch those consumers off do not reach the producers:

input	gates the consumer	gates the producer
record-timings	the timings job (L874)	no — L331 uploads regardless
diagnose	every step that reads the records (L681, L685, L851)	no — L645 and L840 upload regardless
coverage	✓	✓ (L632, L790)
prebuild	✓	✓ (job-level, L344)

So diagnose: false switched off the readers and left the writers running.

What this changes

Three if: guards, using the input names that already exist. No new inputs, no new concepts.

L331   if: ${{ inputs.record-timings }}
L645   if: ${{ always() && inputs.diagnose }}
L840   if: ${{ inputs.diagnose }}

always() on the per-shard records is load-bearing and kept: a failed shard is exactly when its records are worth having. It gains the switch rather than losing the semantics.

Why it matters — measured

With this, coverage: false, diagnose: false, record-timings: false uploads nothing at all.

That was worth establishing empirically, so it was. On FunctionMeasures.jl, with coverage: false alone, against an account whose artifact quota was full:

success       ci / test / Shard labels     ← previously failed here
in_progress   ci / test / shard s1 … s8    ← all eight ran

Before, every run in the fleet died at Shard labels with zero shards executed — main, feature branches and CompatHelper's own branches alike, for eighteen hours.

A suite that creates no artifacts does not care that artifact storage is full. That is a stronger position than keeping storage under the limit, because it does not depend on anyone remembering to prune, and it takes effect immediately — GitHub recalculates quota usage only every 6–12 hours, so deleting artifacts does not unblock anything today.

Scope

This is the part of #78 that needs no design decision. Not included:

• Coverage is still an artifact round-trip when it is on — eight uploads, a download of all of them, a merge, one Codecov upload. Codecov already merges per-flag uploads server-side, so sending from each shard directly would delete the eight artifacts and the merge job and resolve Per-shard coverage artifacts ship 8 copies of the source tree — 85.7% of the payload is text collect already has checked out #74 by removing the payload rather than trimming it.
• The collect job's download (L671) is still unguarded. With coverage: false the steps that consume parts/ are all skipped, so it is inert rather than harmful — but it is the one remaining unguarded artifact operation.
• -prebuild / depot caching belongs with The depot cache has a 0% hit rate: N shards save the SAME key, each uploading the whole depot, and the repo quota evicts everything #72, which reports the depot cache at a 0 % hit rate; moving anything else into that cache before The depot cache has a 0% hit rate: N shards save the SAME key, each uploading the whole depot, and the repo quota evicts everything #72 is fixed would be moving it somewhere already thrashed.

[github-actions]

📚 Docs preview: https://codes.sota-shimozono.com/TestShards.jl/previews/PR79/

(updates on each push to this PR)

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[sotashimozono]

Closing: this does not fix the failure it was opened against, and I said it did.

The three guards are correct in themselves — record-timings and diagnose gate their consumers and did not gate their producers. But they do not clear today's red, and I checked only after opening this:

Every unit ran, exactly once (L810) has no guard. diagnose gates L861 ("Diagnose the shape of the suite"), not the completeness check. So suppressing the -out upload does not suppress the step that reads it — it guarantees the records are absent while the reader still runs. With diagnose: false the run would be more certainly red, not less.

setting	uploads	completeness check	result
defaults	attempted, fail on quota	runs, fails on empty parts/	red
this PR + diagnose: false	none	still runs, fails on empty parts/	red

So the PR body's claim that it restores the fleet was wrong. What it actually buys is that an explicit false stops the upload, which is worth having but is not a recovery path.

Reopening this as part of the real requirement in #80: the split has to work on a free plan, on self-hosted runners, with no artifacts and no hosted runner, while keeping completeness, coverage aggregation and timing history intact. A guard-only change cannot reach that.