A nested module's go.mod-only change skips every Go lane: the changes filter matches go.mod at the root only

[devantler]

🤖 Generated by the Agentic Engineer

Evidence

validate-go-project.yaml's changes job decides whether the Go lanes run at all, and its go filter reads:

go:
  - '**/*.go'
  - 'go.mod'
  - 'go.sum'
  - '.golangci.yml'
  - '.golangci.yaml'

**/*.go is recursive; go.mod and go.sum are root-only. Measured on #1129 (2026-09-04): a pull request whose only change was .github/tests/go-valid-fixture/go.mod — the nested module the workflow's own self-tests point working-directory at — reported go=false, and every Go job (📦 Tidy, 🏗️ Build, 🧪 Test, 🧹 Lint - golangci-lint, 🔍 Dead Code Analysis, 🛡️ Vulnerability Scan, 📊 Code Coverage) finished skipped in all four self-test invocations. Touching a .go file in the same directory made the same change run the full suite.

Impact

The working-directory input exists precisely so a consumer can validate a nested module. For such a consumer, a dependency bump or go mod tidy that edits only go.mod/go.sum (the typical Dependabot shape) skips tidy, build, test and the vulnerability scan while the check reads green. The self-tests in this repository are themselves that consumer, so the fixture can drift without any job noticing. The govulncheck filter already handles this shape correctly ('.govulncheck-allow.txt' and '**/.govulncheck-allow.txt'), which is the pattern to mirror.

Expected behaviour

A go.mod/go.sum change anywhere under the repository is a Go change for the lanes that validate a nested module.

Acceptance criteria

• The go filter matches go.mod, go.sum and the golangci config at any depth, in the same both-forms style the govulncheck filter already uses.
• A contract self-test pins the recursive entries, with an ablation showing it fails when one is dropped.
• A control run on a pull request changing only a nested go.mod reports the Go lanes as run, read from check-run conclusions.

Rough size: S.