Migrate canonical .golangci.yml from gomodguard to gomodguard_v2 #47
Reference in New Issue
Block a user
Delete Branch "fix/25-gomodguard-v2"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Speculative — pending your ruling. Answers #25 and unblocks the downstream sneak/dnswatcher#123.
Policy disclosure up front:
REPO_POLICIES.mdline 261 says.golangci.yml"must NEVER be modified by an agent, only manually by the user". A previous agent read that as binding here too and declined even a branch. This PR was requested explicitly, so it exists as a branch you can merge, amend, or delete. Nothing is merged.Problem
golangci-lint v2.12.0 deprecated
gomodguard. The canonical config usesdefault: all, so the deprecated linter is auto-enabled and every lint run in every consuming Go repo emits:The change
One line, in the existing
linters.disableblock, matching thewslentry directly above it:No settings restructuring was required, because there were no settings to restructure. The canonical config configures no
gomodguardsettings at all — the linter was enabled solely bydefault: all. So there is no module policy to carry across; the migration is exclusively about which linter runs.That is worth stating plainly: the org has never expressed a module allow/block policy through this linter, and this PR does not invent one.
Research findings (v2.12.2 sources, not assumptions)
The settings schema did change materially — it is not a rename. Had settings existed, they would have needed restructuring. From
.golangci.next.reference.ymlat v2.12.2 andpkg/golinters/gomodguard/:gomodguardgomodguard_v2allowed.modules: [string]allowed: [{module: ...}]allowed.domains: [string]Dto{module: "D/.*", match-type: regex}blocked.modules: [{name: {recommendations, reason}}](list of single-key maps)blocked: [{module, recommendations, reason}](flat)blocked.versions: [{name: {version, reason}}]blockedvia aversionfieldblocked.local-replace-directiveslocal-replace-directives, moved to the top level of the settings blockmatch-type: exact(default) /prefix/regexTwo further findings from reading the source rather than the docs:
Migrationfunction ingomodguard.gosilently dropsblocked.versions— it iteratesold.Blocked.Modulesonly. Anyone migrating a config that used version constraints should not trust the auto-suggested output. Not applicable here, but worth recording.linter.NewConfigregistrations inpkg/lint/lintersdb/builder_linter.go; there is no mutual exclusion.gomodguard_v2is therefore already enabled bydefault: all, which is why this PR only disables the old one and adds noenable:block. The warning is attached togomodguarditself, so silencing it requires removing the old one, not adding the new one.Deprecation sweep (issue #25 asked for zero warnings, not just this one):
grepforDeprecatedWarningacross the v2.12.2 registry returns exactly two linters —gomodguardandwsl.wslis already disabled. After this change the canonical config has zero deprecated linters enabled. The sweep that issue #25 noted had never been done is now done, and it is complete.Evidence: the config is genuinely in effect
Verified against a throwaway
sneak/dnswatcherclone at a scratch path (never committed to, never pushed, deleted afterwards) using that repo's ownmake lint. Local golangci-lint is v2.12.2, the pinned version.1. Baseline, canonical config unmodified — reproduces the warning:
2. Negative control — with the candidate config plus a temporary
gomodguard_v2settings block blockinggithub.com/miekg/dns(a direct dependency),make lintFAILS and names the finding:Findings attributed to
gomodguard_v2with a non-zero exit prove three things at once: the linter is enabled bydefault: all, thelinters.settings.gomodguard_v2key is recognised rather than silently ignored, and the flat v2 schema above is the correct one.3. The silent-ignore trap, demonstrated. Same rule, same file, one character changed — key mistyped as
gomodguard-v2instead ofgomodguard_v2:A config that applies nothing is indistinguishable from a clean run. This is the exact failure mode that hid the v1
linters-settingsblock, and it is why the green in step 4 is reported only alongside step 2.4. Reverted to the exact committed candidate — warning gone, clean:
Hashes
021cc83f4e6fc7c31b95b34b846723dfcf20b66b7baeea1dc40406e643346bcb9dc33938311bd7319b21585cba45052f6edb1ab4305dafcd3816abd7ffd18a5bEvery repo vendoring this file must re-vendor it after merge. Consuming repos verify by sha256 and will mismatch the moment this lands: dnswatcher, webhooker, vaultik, rgoue, cattbox, sfdupes, attrsum, upaas, simplelog, mfer, secret, bsfirehose, pixa. Open issues asserting the old hash also need re-baselining — sneak/dnswatcher#123 among them. A propagation issue is warranted on merge; I have not filed one, since it is moot if you close this.
For the record,
REPO_POLICIES.mddoes not currently publish the config's sha256 anywhere, so nothing in it needs updating for this change. Issue #25's definition of done assumed it did.Validation
make fmtproduced no changes (it formats markdown only; this is YAML).make checkpasses.[manager] One ruling needed, independent of whether you take this PR.
REPO_POLICIES.mdline 261 forbids agents from modifying.golangci.yml, unqualified. Read literally that also forbids editing the canonical copy here — which is the only place it can ever be fixed. An earlier agent read it that way and declined to open even a speculative branch; this one proceeded because the PR was explicitly requested. The rule as written contradicts the practice, so it recurs on every agent that meets it.Options:
.golangci.yml; changes go tosneak/prompts". Keeps the protection that matters (no local divergence) and unblocks the only place fixes can land.Recommendation: option 1. The rule's purpose is preventing silent per-repo divergence from canonical, not freezing canonical itself. Option 2 also means the deprecation warning in this PR could only ever be fixed by you by hand.
Assigning to you for the ruling. Not blocking anything — dnswatcher work continues either way.
View command line instructions
Checkout
From your project repository, check out a new branch and test the changes.