Each partition uploaded its own report and left Codecov to combine them,
which had two problems. A partition that failed still let the other five
report, so a run that lost a sixth of its tests produced a quietly lower
number rather than no number. And with -coverpkg every partition's
profile carries the whole block set, mostly zeroed, so combining them
meant relying on Codecov's merge -- the same merge that mishandles
duplicate blocks within a file.

Have each partition keep its raw coverage data as an artifact and add one
job that merges all of them with "go tool covdata" and uploads a single
report. Needing the test job is what makes this safe: a job runs only
once every leg of the matrix it needs has succeeded, so a failed
partition means no upload at all rather than a report missing part of the
run, and nothing about the result depends on how Codecov combines
reports.

For the nightly that also means a failure on macos or arm holds back the
baseline for that commit, since they share one matrix with the platform
that measures coverage. Codecov walks back to the nearest ancestor that
has a report, so a gap costs a comparison against a slightly older base
rather than a missing one.

Verified that the merge reconstructs a partitioned run: over config,
util/metrics and data/bookkeeping, partition 0 alone covers 15.6% and
partition 1 alone 23.0%, while the two merged give 25.8%, exactly the
unpartitioned figure.

merge_coverage.sh now takes the output first and any number of coverage
data directories after it. Drop comment.after_n_builds with the extra
uploads: there is one report per commit now, so there is nothing to wait
for, and the setting would have meant a comment never appearing at all if
one upload went missing.

Each partition uploaded its own report and left Codecov to combine them,
which had two problems. A partition that failed still let the other five
report, so a run that lost a sixth of its tests produced a quietly lower
number rather than no number. And with -coverpkg every partition's
profile carries the whole block set, mostly zeroed, so combining them
meant relying on Codecov's merge -- the same merge that mishandles
duplicate blocks within a file.

Have each partition keep its raw coverage data as an artifact and add one
job that merges all of them with "go tool covdata" and uploads a single
report. Needing the test job is what makes this safe: a job runs only
once every leg of the matrix it needs has succeeded, so a failed
partition means no upload at all rather than a report missing part of the
run, and nothing about the result depends on how Codecov combines
reports.

For the nightly that also means a failure on macos or arm holds back the
baseline for that commit, since they share one matrix with the platform
that measures coverage. Codecov walks back to the nearest ancestor that
has a report, so a gap costs a comparison against a slightly older base
rather than a missing one.

Verified that the merge reconstructs a partitioned run: over config,
util/metrics and data/bookkeeping, partition 0 alone covers 15.6% and
partition 1 alone 23.0%, while the two merged give 25.8%, exactly the
unpartitioned figure.

merge_coverage.sh now takes the output first and any number of coverage
data directories after it. Drop comment.after_n_builds with the extra
uploads: there is one report per commit now, so there is nothing to wait
for, and the setting would have meant a comment never appearing at all if
one upload went missing.

Component ids are immutable once used, so the split is worth settling
deliberately rather than guessing at it here. There is also nothing yet
worth measuring them against: every report Codecov currently holds is
either partial-coverage or scrambled by the duplicate-block bug, and
component analytics backfill over whatever history exists.

Adding them later costs nothing -- they are defined entirely in this file
and need no change to the uploads -- and by then people will have been
reading the new comments and can say what split they actually want.