CI: submodule coverage is uploaded three times and merged nowhere; parse_coverage computes a number nothing reads

[akshat-kumar-singhal]

Summary

Since #3824 was fixed (PR #3825), Submodule-Unit-Testing does produce submodule-coverage-reports. Two problems remain downstream of that, and the net effect is that submodule coverage still does not reach the reported number — it is now generated, uploaded three times, and read by nothing.

1. The submodule artifact has no matrix guard, so it is uploaded once per Go version

Example-Unit-Testing and PKG-Unit-Testing both gate their upload:

- name: Upload Test Coverage
  if: ${{ matrix.go-version == '1.24'}}

Submodule-Unit-Testing (.github/workflows/go.yml:381) has no such gate, so all three legs upload under the same name. From run 31266842627:

submodule-coverage-reports  51754  2026-08-08T16:28:58Z
submodule-coverage-reports  51754  2026-08-08T16:27:25Z
submodule-coverage-reports  51754  2026-08-08T16:27:25Z
PKG-Coverage-Report        281781  2026-08-08T16:26:04Z
Example-Test-Report          8602  2026-08-08T16:25:41Z

Three artifacts, same name, identical size. actions/upload-artifact@v7 permits the duplicate names (v4 would have 409'd), so nothing complains.

2. Nothing consumes it

Both merge steps hardcode two paths:

grep -h -v "mode:" ./Example-Test-Report/profile.cov ./PKG-Coverage-Report/profile.cov >> merged_profile.cov

— in parse_coverage (go.yml:277) and again in upload_coverage (go.yml:422). Neither job needs: the submodule job either, so parse_coverage doesn't even see the artifact; its log for the run above reads:

Found 2 artifact(s)
- PKG-Coverage-Report (ID: 9024428262, ...)
- Example-Test-Report (ID: 9024423628, ...)

It started at 16:27:02, before two of the three submodule uploads had finished. So the 86.2% published to qlty excludes every module under pkg/gofr/datasource/* — 27 submodules — while appearing to be a whole-repo figure.

upload_coverage has the same two-file merge, so the same gap reaches qlty on development pushes.

3. parse_coverage is decorative

- name: Parse code-coverage value
  run: |
    codeCoverage=$(go tool cover -func=merged_profile.cov | grep total | awk '{print $3}')
    codeCoverage=${codeCoverage%?}
    echo "CODE_COVERAGE=$codeCoverage" >> $GITHUB_ENV

CODE_COVERAGE is written to $GITHUB_ENV and read by nobody — its only consumer, the 92% threshold gate, is commented out directly below at go.yml:288-292. The job's entire output is one echo line in a log. It also runs go tool cover with no actions/setup-go step, so it silently depends on whatever Go the ubuntu-latest image happens to ship.

Expected

• One submodule-coverage-reports artifact per run, not three.
• parse_coverage and upload_coverage needs: the submodule job and merge its profiles, so the published percentage covers the submodules.
• parse_coverage either gets its threshold gate back (making it a real gate) or is folded into upload_coverage and deleted.
• An explicit setup-go wherever go tool cover runs.

Caveats for whoever takes this

• Merging submodule coverage in will move the reported number, possibly down, since the datasource modules were never counted. That is the correct number, but expect the qlty delta to look alarming on the PR that lands it.
• -coverpkg=./... is per-module in the submodule job, so the merged profile will contain entries from several modules — worth checking qlty coverage publish --strip-prefix still resolves paths for them.
• CI: the Go version matrix runs 1.26 on every leg; setup-go-toolchain exists only to sustain it #3859 notes that the matrix.go-version == '1.24' gate should move to the version that actually runs; whichever gate the submodule upload gets should use the same one, so this doesn't need fixing twice.

Context

Found while reviewing run 31266842627. Downstream of #3824 / #3825; related to #3859.