sneak/dnswatcher
1
0
Fork 0
Code Issues 37 Pull Requests 8 Actions Packages Projects Releases Wiki Activity

DECISION NEEDED: gomodguard linter is deprecated, and .golangci.yml can only be changed by you #123

New Issue
Open
opened 2026-08-09 08:05:15 +02:00 by clawbot · 1 comment
clawbot commented 2026-08-09 08:05:15 +02:00
Collaborator
Copy Link

@sneak — this one is yours by construction, because the only file that can fix it is one no agent is permitted to touch.

Situation

Every make lint run in this repo emits:

level=warning msg="The linter 'gomodguard' is deprecated (since v2.12.0) due to: new major version. Replaced by gomodguard_v2."
level=warning msg="Suggested new configuration:\nlinters:\n  enable:\n    - gomodguard_v2\n"

This is not caused by any PR in the 1.0 milestone — it is present on main and appears on every branch. It surfaced on PR #113 (where the reviewer correctly flagged it as pre-existing and declined to chase it) and again on #112 and #118 during lint revalidation.

The trigger is the golangci-lint v2.12.2 upgrade that landed in PR #96: gomodguard was deprecated in v2.12.0, exactly the version this repo pinned to.

Why I am not fixing it

REPO_POLICIES.md is unambiguous:

> .golangci.yml is standardized and must NEVER be modified by an agent, only manually by the user.

The fix is a one-line change in .golangci.yml (gomodguard → gomodguard_v2), and that file is off limits to me. Its sha256 must remain 021cc83f4e6fc7c31b95b34b846723dfcf20b66b7baeea1dc40406e643346bcb in every PR I approve, and I have been verifying exactly that on each one.

There is a second reason to route this through you rather than around it: the config is org-standard and shared. Every Go repo on the same pinned linter has this warning. Fixing it here alone would fork this repo's config away from the canonical one and break the sha256 check that several open issues rely on. The change belongs upstream in the prompts repo, then propagates.

Options

  1. Update the canonical .golangci.yml upstream (gomodguard → gomodguard_v2), then propagate the new file and its new sha256 to every Go repo. Correct and durable. Requires touching the shared template and re-baselining the hash everywhere it is asserted.
  2. Leave it. It is a warning, not an error — make lint still reports 0 issues. and the gate is not compromised. Cost is permanent noise on every lint run, which is the specific condition under which real signals get overlooked.
  3. Defer past 1.0. Tag the release with the warning present and fix it in the next config refresh.

Recommendation

Option 1, upstream, but not as a 1.0 blocker. The warning is cosmetic today and nothing in the gate depends on gomodguard specifically. But standing warnings are how genuine ones get missed, and this repo has already been bitten three times this milestone by checks that looked authoritative and were not (#115, #117, #121). Clearing avoidable noise from the one gate that still reports honestly is worth doing — just not on the critical path to tagging.

If you would rather I do nothing at all here, say so and I will close this.

Definition of done (whichever option you pick)

  1. make lint emits no deprecation warnings, or this issue is closed with a decision recorded.
  2. If the config changes, the new sha256 is published so agents can keep verifying it — several open issues (#109, #115, #117, #119, #121) assert the current hash, and they will all need the new value.
  3. The linter version pin c0d3ddc9cf3faa61a4e378e879ece580256d76e5 is unchanged; this is a config change, not a version bump.

Related

Three other gate-integrity defects found this session, all filed and none of them requiring your intervention: #115 (script/cibuild reports an unearned green from the Docker layer cache), #117 (script/bootstrap skips the pinned linter install, so the running linter may not be the pinned one), #121 (script/lint shares one golangci-lint cache and lock across concurrent worktrees, so a result can come from a different codebase). All three are tracked upstream too.

@sneak — this one is yours by construction, because the only file that can fix it is one no agent is permitted to touch. ## Situation Every `make lint` run in this repo emits: ``` level=warning msg="The linter 'gomodguard' is deprecated (since v2.12.0) due to: new major version. Replaced by gomodguard_v2." level=warning msg="Suggested new configuration:\nlinters:\n enable:\n - gomodguard_v2\n" ``` This is not caused by any PR in the 1.0 milestone — it is present on `main` and appears on every branch. It surfaced on [PR #113](https://git.eeqj.de/sneak/dnswatcher/pulls/113) (where the reviewer correctly flagged it as pre-existing and declined to chase it) and again on [#112](https://git.eeqj.de/sneak/dnswatcher/pulls/112) and [#118](https://git.eeqj.de/sneak/dnswatcher/pulls/118) during lint revalidation. The trigger is the golangci-lint **v2.12.2** upgrade that landed in PR #96: `gomodguard` was deprecated in v2.12.0, exactly the version this repo pinned to. ## Why I am not fixing it `REPO_POLICIES.md` is unambiguous: > `.golangci.yml` is standardized and must _NEVER_ be modified by an agent, only manually by the user. The fix is a one-line change in `.golangci.yml` (`gomodguard` → `gomodguard_v2`), and that file is off limits to me. Its sha256 must remain `021cc83f4e6fc7c31b95b34b846723dfcf20b66b7baeea1dc40406e643346bcb` in every PR I approve, and I have been verifying exactly that on each one. There is a second reason to route this through you rather than around it: the config is **org-standard and shared**. Every Go repo on the same pinned linter has this warning. Fixing it here alone would fork this repo's config away from the canonical one and break the sha256 check that several open issues rely on. The change belongs upstream in the `prompts` repo, then propagates. ## Options 1. **Update the canonical `.golangci.yml` upstream** (`gomodguard` → `gomodguard_v2`), then propagate the new file and its new sha256 to every Go repo. Correct and durable. Requires touching the shared template and re-baselining the hash everywhere it is asserted. 2. **Leave it.** It is a warning, not an error — `make lint` still reports `0 issues.` and the gate is not compromised. Cost is permanent noise on every lint run, which is the specific condition under which real signals get overlooked. 3. **Defer past 1.0.** Tag the release with the warning present and fix it in the next config refresh. ## Recommendation **Option 1, upstream, but not as a 1.0 blocker.** The warning is cosmetic today and nothing in the gate depends on `gomodguard` specifically. But standing warnings are how genuine ones get missed, and this repo has already been bitten three times this milestone by checks that looked authoritative and were not (#115, #117, #121). Clearing avoidable noise from the one gate that still reports honestly is worth doing — just not on the critical path to tagging. If you would rather I do nothing at all here, say so and I will close this. ## Definition of done (whichever option you pick) 1. `make lint` emits no deprecation warnings, **or** this issue is closed with a decision recorded. 2. If the config changes, the new sha256 is published so agents can keep verifying it — several open issues (#109, #115, #117, #119, #121) assert the current hash, and they will all need the new value. 3. The linter version pin `c0d3ddc9cf3faa61a4e378e879ece580256d76e5` is unchanged; this is a config change, not a version bump. ## Related Three other gate-integrity defects found this session, all filed and none of them requiring your intervention: #115 (`script/cibuild` reports an unearned green from the Docker layer cache), #117 (`script/bootstrap` skips the pinned linter install, so the running linter may not be the pinned one), #121 (`script/lint` shares one golangci-lint cache and lock across concurrent worktrees, so a result can come from a different codebase). All three are tracked upstream too.
clawbot added this to the 1.0 milestone 2026-08-09 08:05:15 +02:00
sneak was assigned by clawbot 2026-08-09 08:05:15 +02:00
clawbot commented 2026-08-10 15:50:58 +02:00
Author
Collaborator
Copy Link

[manager] Still reproducing — the gomodguard deprecation warning appears on every Docker lint run after #134 landed. No new issue filed; this one already covers it.

Confirming the constraint holds: .golangci.yml is org-canonical and must not be edited downstream, so the migration to gomodguard_v2 belongs in sneak/prompts and then fans out to every repo vendoring it. Nothing to do here until that lands.

**[manager]** Still reproducing — the `gomodguard` deprecation warning appears on every Docker lint run after https://git.eeqj.de/sneak/dnswatcher/issues/134 landed. No new issue filed; this one already covers it. Confirming the constraint holds: `.golangci.yml` is org-canonical and must not be edited downstream, so the migration to `gomodguard_v2` belongs in `sneak/prompts` and then fans out to every repo vendoring it. Nothing to do here until that lands.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
merge-ready
All checks pass, reviewed, rebased, ready for merge
 needs-checks
make check does not pass cleanly
 needs-rebase
PR has merge conflicts or is behind main
 needs-review
Code review not yet done
 needs-rework
Code review found issues to fix
No Label
Milestone
No items
No Milestone 1.0
Projects
Clear projects
No project
Assignees
Clear assignees
clawbot sneak
No Assignees sneak
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: sneak/dnswatcher#123
Delete Branch "%!s()"

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?