Lint gate is red on every pull request, and main never runs it

[devantler]

🤖 Generated by the Daily AI Engineer

Evidence

The 🧹 Lint - mega-linter job fails on pull requests against main for defects that are already on main. Measured on #2769 — a pull request whose entire diff is one new .coderabbit.yaml file, which cannot influence Go or duplication linting (run 29809153393):

• revive — 2 errors. scripts/validate-merge-group-heal/main.go:1:1 and scripts/validate-eks-ci-role-policy/main.go:1:1: should have a package comment. Both files are present on main today without one.
• jscpd — 24 clones, 2.4% against a 0.0% threshold. 16 of them are inside scripts/validate-eks-ci-role-policy/main_test.go (landed in fix(aws): allow EKS version discovery #2753 this morning); 4 are inside scripts/tests/test_refresh_flux_ghcr_auth.py and scripts/tests/test_validate_homepage_bookmarks.py.
• zizmor — 1 error, artipacked on cd.yaml failing with 401 Unauthorized while listing tags for actions/checkout. This one is a transient GitHub API condition, not a repository defect.

The reason nobody noticed is the second half of the problem: the job does not run on main at all. The most recent push-to-main Code Quality run (29806818885) contains exactly one job, Analyze (python). So main reports green while carrying lint defects, and every pull request inherits them.

Who this affects, and how much

Every open pull request on this repository — currently 40+ drafts — displays a red Lint check that has nothing to do with its own diff. That makes the check unusable as a signal: a genuine lint regression introduced by a PR is indistinguishable from the inherited noise, so it will be waved through. It also costs a full 5-minute lint run per PR to re-report the same pre-existing failures.

Expected behaviour

A pull request that introduces no lint defect shows a green Lint check, and a defect that reaches main is caught when it lands rather than surfacing on unrelated pull requests afterwards.

Acceptance criteria

• revive reports 0 errors across the repository.
• jscpd reports 0 clones, with the threshold left at 0.0% — deduplicated at the source, never raised or ignored.
• The lint gate also runs on pushes to main, so a defect cannot land silently again.
• The Python clones are recorded against the existing bash/Go migration work rather than papered over.

Rough size: M — the revive fix is two lines; the Go duplication is a table-driven test refactor in one file; the main-branch coverage is a workflow trigger change.

[coderabbitai]

🔗 Related PRs

#2330 - ci: heal prod when a merge-group deploy fails (restore main) [merged]
#2339 - docs(agents): record merge-queue mechanics + root-cause-before-requeue [merged]
#2401 - ci: repoint reusable workflows to actions v8.0.0 [merged]
#2418 - ci: bump devantler-tech/actions pins to v9.0.0 [merged]
#2622 - fix(ci): heal cancelled merge-group deploys [merged]

---

📝 Issue Planner

_{Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.}

• Create Plan

---

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!

[devantler]

🤖 Generated by the Daily AI Engineer

Closing as a duplicate of #2780, which was filed independently about twenty minutes after this one and is the better description of the same problem.

Mine reached the right symptom from a single failing run and stopped at the three blocking linters I happened to grep for. #2780 inventoried the whole job — ten linters, including a 8051-finding cspell baseline and a mis-detected schema in v8r — and got the mechanism right where I had it wrong: the job is paths-filtered onto the Go validation path, so it is skipped by the k8s/** changes that make up nearly every PR here. It is not main breakage, which is what I had assumed.

Everything actionable has moved across: #2777 and #2778 are now sub-issues of #2780, and #2779 is closed because its premise came from my incorrect reading. #2776 stays open — it clears revive to zero and removes six of the duplication findings, which is a real subset of #2780's first acceptance criterion.

Superseded by #2780.