Fix: Honour go.mod toolchain and wire Sonar coverage

[ModeSevenIndustrialSolutions]

Follows the Phase 1 sequencing in the interim evaluation (#51), taking the two items whose blockers have now cleared. One topic — the lanes consuming their dependencies correctly — and one atomic commit each, plus a commit carrying review feedback.

The Go half did not land where the issue expected. Investigating #43 turned up a live defect in the CLM lane, and showed that implementing #43 as written would have spread it rather than fixed it.

Commits

Fix: Honour the go.mod toolchain directive — closes #43

This is a live bug, not a consistency tidy-up. sonatype-lifecycle.yaml could not scan any Go project that pins a toolchain newer than its go directive.

Three actions/setup-go behaviours combine badly:

Behaviour	Verified against
v6+ reads both directives from go-version-file and prefers toolchain	parseGoVersionFile in src/installer.ts, identical at v6.5.0 and v7.0.0
go-version beats go-version-file outright	resolveVersionInput in src/main.ts
It exports GOTOOLCHAIN=local for the rest of the job	setGoToolchain(), src/main.ts:181

The lane passed build-metadata-action's go_go_version — documented as "Minimum Go version declared in go.mod (go directive)" — as go-version. That suppressed the file, so the toolchain directive never applied. And because GOTOOLCHAIN=local stops Go fetching the toolchain the module asks for, the result is a hard stop rather than a build on an older Go:

go: go.mod requires go >= 1.25.3 (running go 1.23.0; GOTOOLCHAIN=local)

The fix is to drop go-version and let setup-go read the file, which is the only form honouring both directives. build-metadata-action does emit go_toolchain alongside go_go_version, so a correct value could be composed — but that restates parsing setup-go already does, including rc toolchains and the GOTOOLCHAIN=local escape.

Go also leaves the Gather build metadata step, since nothing consumed its output on that path any more. That step compiles a Go binary at runtime, so Go scans lose a build they never needed.

Why this closes #43 rather than implementing it. The issue proposed extending build-metadata-action to the Sonar lane's Go path for consistency with the JDK. The Sonar lane turns out to be the one already correct: it reaches setup-go through go-test-action, whose go_version_file defaults to go.mod and yields only to an explicit go_version. The lanes are now aligned — on go-version-file, the opposite direction to the one proposed. The JDK analogy does not carry over, because setup-java cannot read a build file this way.

Feat: Wire build coverage paths into the Sonar scan — closes #70

Unblocked: the coverage_report_paths input the issue was waiting on landed in sonarqube-cloud-scan-action v1.5.0 (published today), which this bumps to.

maven-build-action has aggregated reactor coverage since v0.4.0 and the lane consumed neither end. Maven analysis mode derives report paths from the project model and was fine; CLI mode never reads that model, so coverage rested on sonar-project.properties or a default glob — a reactor reporting anywhere else scanned with no coverage, and stale reports from an earlier step scanned with the wrong coverage.

An empty value is a statement rather than an absence, so a Maven build that measured no aggregate now says so in the log and job summary. The message names the benign causes (project-owned coverage data, no JaCoCo agent) so it does not read as a failure.

Adds the CLI-mode self-test leg the issue's Validation section asks for. See the caveat under review feedback below — that leg proves less than it appears to.

Docs: Record the Go toolchain and coverage decisions

D21 and D22 in docs/BRIEF.md, both recording an inversion of what was previously assumed.

Fix: Address Copilot review feedback

Two items, both valid — see the resolved threads.

1. D21/D22 were anchored on a link reference definition that sits inside D20 rather than at its end, so they spliced into the middle of that section and left D20's closing paragraph stranded after them, still describing the behaviour D21 replaces. The record documented the fixed and the broken implementation at once, with the broken one reading as current because it came last. Sections moved after D20; that paragraph rewritten rather than deleted, so the java_version analogy that motivated the original design is still on record along with why it fails for Go.
2. The new CLI-mode self-test cannot fail. test-maven-project declares sonar.coverage.jacoco.xmlReportPaths in its own sonar-project.properties, so the Scanner CLI finds reactor coverage whether or not the lane forwards anything. Removing that property is not an option — the fixture's own comment says keeping both analysis modes working is the point of it — and the log assertion Wire coverage_report_paths from the build into the Sonar scan #70 asks for is unreachable, since sonarqube-cloud-scan-action exposes no output carrying the assembled arguments. Raised as CLI-mode coverage self-test cannot fail: the fixture supplies the property #77; the job now states what it does and does not prove.

Issues raised from this work

• No Go fixture with a toolchain directive, so version selection is untested #75 — no Go fixture carries a toolchain directive, so nothing in CI exercises the D21 path. The CLM defect fixed here shipped in Feat: Add a Go build_type to the Sonatype Lifecycle lane #38 and passed every Go self-test throughout, because test-go-project's go.mod has nothing to get wrong.
• CLI-mode coverage self-test cannot fail: the fixture supplies the property #77 — the CLI-mode coverage leg cannot fail, per the review item above.

Both are the same shape as the existing #74, and #77 notes the pattern: three self-tests that exercise a path they cannot see fail, each a silent-failure mode of the kind docs/BRIEF.md D12 warns about. Worth one deliberate pass at fixture coverage rather than three separate patches.

Ready to close without code

The audit recorded in #73 already answers two open issues on their own stated terms; neither needs an implementation:

• No per-project build environment on either scan lane (ENV_VARS/ENV_SECRETS) #59 — ENV_SECRETS is the literal "{}" in every in-scope caller, and ENV_VARS carries only MAVEN_OPTS (covered by mvn_opts) or two Sonar-shaped keys whose effect on that code path is doubtful. The issue's step 2 says record and close.
• Neither scan lane can name a non-standard POM file (MVN_POM_FILE) #61 — MVN_POM_FILE has four callers and every value names a file called pom.xml; only the directory varies, which path_prefix already selects. The issue says closing with a note in docs/BRIEF.md is the right outcome, and that note is in main.

Happy to close both, or to implement mvn_pom_file as plumbing if you would rather have the input than the decision — say which.

Still blocked or sequenced later

• Verify Nexus IQ ingestion of syft-generated CycloneDX SBOMs #39 needs live Nexus IQ access for the syft-vs-cyclonedx-gomod comparison; it gates all of Cluster A (Generalise the Nexus IQ SBOM upload path beyond Go #40, Add a Python build_type to the Sonatype Lifecycle lane #42's SBOM half).
• Adopt go.list as the Go scan target for the Sonatype Lifecycle lane #41 is deliberately sequenced after Gerrit example and migration guidance for the Go CLM path #50's policy-opa-pdp cutover, per the PR Feat: Add a Go build_type to the Sonatype Lifecycle lane #38 review agreement.
• Gerrit example and migration guidance for the Go CLM path #50's remaining half is the ONAP caller itself, outside this repository.
• No submodule-bearing fixture, so submodule scanning is untested #74, No Go fixture with a toolchain directive, so version selection is untested #75, CLI-mode coverage self-test cannot fail: the fixture supplies the property #77 need fixtures that do not exist yet.

Validation

• prek run --all-files — passed
• zizmor --persona auditor .github/workflows/ examples/ — no findings
• aislop ci — 0 errors, 0 warnings (0 files in scope for this repository)
• The new job-summary script extracted and run under bash to confirm the heredoc and warning render correctly
• Action pin c8c342bf621f6e7e8622b12a19fa3539a6237f3c is the commit for v1.5.0, dereferenced from the tag object

Not run: testing.yaml, which is workflow_dispatch-only and needs organisation credentials. Worth dispatching against this branch before release — though note per #77 that the coverage leg will pass either way until a discriminating fixture exists.

[Copilot]

Pull request overview

Fixes Go toolchain selection and forwards Maven JaCoCo coverage paths into Sonar analysis.

Changes:

• Reads Go versions directly from go.mod.
• Wires Maven coverage paths into Sonar scans.
• Adds CLI-mode validation and records design decisions.

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 2 comments.

File	Description
docs/BRIEF.md	Documents toolchain and coverage decisions.
.github/workflows/testing.yaml	Adds Maven CLI-analysis coverage.
.github/workflows/sonatype-lifecycle.yaml	Honors the toolchain directive.
.github/workflows/sonarqube-cloud.yaml	Passes generated coverage paths to Sonar.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[Copilot]

Pull request overview

Copilot reviewed 4 out of 4 changed files in this pull request and generated no new comments.

[zxiiro]

🤖 Auto-approved by agent: reviewed workflow/code change for security and CI/CD impact, found low risk. Wires Maven coverage_report_paths into Sonar scan; Setup Go reads go.mod via go-version-file to honour toolchain. Additive/compatible; SHA pins retained; no widened permissions.