Fail a pull request whose Go modules are not tidy #5326

🤖 Generated by the Agentic Engineer

Evidence

#5314 (a Renovate go-github major bump) merged on 2026-10-25 with a go.mod change that go mod tidy reverts: it added an unused go-github/v93 requirement while the code still imports v88. Every required check passed. A second proposal, #5321, then went red on the vulnerability scan with go: updates to go.mod needed, which is the first place an untidy module showed up. #5325 removes the leftover.

Audience and problem

Maintainers and dependency automation. An untidy root module can merge silently, and the failure surfaces later, on an unrelated PR, as a scan "operational error" rather than as a clear module finding.

Hypothesis

A required check that fails when go mod tidy would change go.mod or go.sum, in every tracked Go module, stops a go.mod-only update that does not match the code from merging.

Success signal

A go.mod-only change that leaves an import on the old module path fails a required check on its own PR, with a message naming the fix. Check on the next go.mod-only Renovate proposal.

Smallest useful change

Find where the organization Go workflow builds and tests this repository's modules, and add a tidy check there (shared, so other Go repositories inherit it) or in this repository's CI if the shared workflow cannot take it.

Acceptance criteria

• An untidy go.mod or go.sum fails a required check on the PR that introduces it.
• The failure message says to run go mod tidy in the named module.
• A tidy tree passes, proven on a real PR.

Refinement — 2 November 2026

The gap is still present at 76d1bd244a9b9678fd9c753518d1a0bd152b456e. Platform's primary language is Shell, so the organization rule restricted to Go repositories does not enroll it. Its unconditional required Go regression job runs tests but performs no systematic tidy comparison. There are nine tracked modules, including isolated admission/compiler helpers and the intentional vulnerability-control fixture; checking only the root would leave the other module boundaries uncovered.

The original #5314 regression job and required aggregate both succeeded with the unused dependency. #5321's later module-loading error is a particular refusal, not evidence that a general tidy guard exists.

Implement a repository-local, read-only all-tracked-module check before the existing required Go regression command. Preserve the intentional vulnerability fixture's old Go declaration and all existing checks. Reject incomplete module discovery and failed tidy execution; include root and nested modules, sum-only drift and a missing sum file in meaningful controls. Name the affected module and go mod tidy in failure diagnostics. Prove that checking leaves module files unchanged. Existing required aggregation must propagate a selected guard failure; no new credentials, services, cache writer or organization-wide workflow is needed.

High priority / Medium effort / Risk reduction: this prevents an unrelated future proposal from inheriting a module failure that should have been rejected at its source. This is not a production incident expedite. The issue is an independently implementable child of #4979, with no live dependency blocker.