A caller cannot give the shards env, or collect artifacts from them

[sotashimozono]

Two gaps, found together while migrating the largest suite in the fleet, which cannot adopt this workflow because of them.

1. No per-shard environment

A consumer's runtests.jl may read environment the workflow has to set. QAtlas.jl's does:

var	value
QATLAS_TEST_PROFILE	full on the default branch, fast on a pull request
QATLAS_EMIT	1 on the default branch
QATLAS_CIOUT_DIR	pinned into the workspace, because Pkg.test sandboxes the suite

The reusable sets its own TESTSHARDS_* and nothing else. So the suite falls back to its default profile everywhere — including the branch that is supposed to run the full one.

That is the bad kind of failure: nothing goes red, the run just tests less than it did. A migration that does this silently is worse than one that breaks loudly.

2. No way to collect a caller's artifacts from the shards

The same suite emits evidence-*.jsonl verification cards from each shard and merges them, on the default branch, into a ci-evidence orphan branch — its own record of what has been verified, independent of coverage and of the test records this package already merges.

The reusable uploads <prefix>-coverage-*, <prefix>-out-* and its own report, and offers no hook for anything else. So a consumer with a per-shard side product has to keep a separate unsharded job to produce it, which is the cost the sharding was meant to remove.

Shape of a fix

• env: — a caller-supplied block, merged into the shard job's environment. It has to be per-shard, not per-run, because the values can depend on matrix.sid.
• collect-artifacts: — a glob the shard job uploads under the caller's prefix, plus the matching download in a caller-side job. upload-artifact's if-no-files-found: ignore makes the empty case free.

Both are additive and default to nothing.

Why it took until now

Twenty-odd repositories adopted this without needing either, because their test jobs set no environment and produced nothing but coverage. The one that needs both is the one with the most to lose from a quiet regression.

[sotashimozono]

Two corrections before anyone implements this, one of them mine.

The per-shard claim was wrong

I wrote that env: "has to be per-shard, not per-run, because the values can depend on
matrix.sid". Checked against the consumer that motivated this: none of its variables depend
on the shard. The two that did — a file list and a flag — were the old planner's selection
protocol, which this workflow replaces outright. What remains is per-run and computable in the
caller's own with:.

So the input is a plain multi-line KEY=value string that a shard writes into $GITHUB_ENV.
Roughly thirty lines for both halves, not a design problem.

The line this must not cross

The risk here is building one consumer's CI into a general package, and the two features are on
opposite sides of that line depending on how they are shaped.

Transport, yes:

input	what it does	why it is general
env	KEY=value lines into the shard's environment	any suite with a fast/full profile, a fixture directory, a thread count
collect-artifacts	a glob the shard uploads under the run's prefix	any suite whose shards produce something besides coverage — benchmarks, figures, logs

Policy, no. None of these belong here, however convenient they would be for the consumer that
prompted the issue:

• merging the collected artifacts (jq, JSONL, or anything else — that is the caller's format)
• pushing them to an orphan branch
• knowing any directory name the caller uses to emit them
• an input named after what one project calls its side product

The workflow hands the environment in and the files out. What they mean is not its business.

The test to apply: would this input make sense written down for someone who has never seen
the repository that motivated it? env and collect-artifacts pass. emit-evidence would not.