Repository navigation
Shared Go lint tools reject declared Go 1.27 modules before analysis #577
Description
🤖 Generated by the Agentic Engineer
Expected Behavior
Required validation must examine the declared Go module with a compatible lint tool. Preserve existing lint rules, real finding rejection, read-only fixer credentials, module selection and complete test scope. Newer Go consumers must not fail before analysis because the shared linter binary was built with an older compiler.
Actual Behavior
Business-site PR #63 at ef9f6d24f4156125ee8658ec92f671b7aef52e8e has successful source CI and successful actual shared PostgreSQL Test/race-Coverage, but required run 38308431280 fails in golangci-lint job 115008684139. Setup installs the declared Go 1.27.2; the shared action installs v2.11.4, built with Go 1.26, and rejects the target before reading the code. The maintained workflow has the same version. This is a reproduced producer incompatibility, not a failed portal test or review waiver.
The frozen legacy MegaLinter job 115008684203 also runs its container compiler as Go 1.26.3 despite host setup of 1.27.2. The maintained catalogue already binds the container compiler to the exact setup output; only the urgently needed compatible mirror belongs in the legacy repository. Its other actual source/template/style/dictionary findings remain separate and must not be discarded when repairing the toolchain.
Steps to Replicate
- Use a tracked Go module declaring Go 1.27.2.
- Execute the current shared Go linter action with its pinned v2.11.4 tool.
- Observe the explicit compiler-versus-target incompatibility before lint analysis. The actual consumer job above is the executed RED.
- In legacy validation, observe the container's Go 1.26.3 module-loading failure independently of host setup.
Acceptance Criteria
- Bind production and native lint-finding fixtures to a reviewed compatible linter version; keep the action SHA, all rules, full scope and credential boundaries intact.
- Retain older supported Go coverage, and exercise a Go-1.27 fixture that proves genuine lint-finding rejection rather than an operational install/config failure.
- Regenerate the maintained read-only projection with its generator; never hand-edit it.
- Deliver maintained compatibility first, then the urgent frozen-legacy mirror with its exact container compiler binding and native regression controls.
- Validate all affected contracts, current-head native CI and substantive ordered review; use normal protected merges and verify release before consumer adoption.
- Preserve and repair every other reported consumer finding. Re-run the actual required consumer; no disabled linter, suppression, skipped test or protection change is permitted.
Priority High, effort Medium, service class Standard: this blocks an already-started client-portal delivery. The end-to-end estimate includes maintained/legacy review, releases and actual consumer verification. This does not enable real client intake, payment or execution.
Part of #287. The broader PostgreSQL rollout remains #573; this new compiler failure must clear before its pilot is complete.
Metadata
Metadata
Assignees
Labels
Type
Fields
Priority
Effort
Projects
- Status
Activity
chore: agent-claim #577 nonce=010e9a10bcf2d2a258cb0acca5335fc2
devantler commentedon Oct 13, 2026
Actual consumer adoption is partially verified, not complete. The released legacy repair v13.10.11 now supplies the compatible standalone analyzer and declared container compiler. Business-site head
baff2956df0aaa05c63d20e9c197379db6f9434f, required run 38323828388, confirms the standalone Go analyzer, PostgreSQL Test, race Coverage, build, tidy, vulnerability and dead-code jobs succeeded. The container now uses the declared Go 1.27.2, and actual package-context and HTML analysis also succeed.The same run exposes a second, distinct compatibility defect: MegaLinter's embedded golangci-lint v2.13.2 cannot load Go 1.27 export data (
version 5 > maximum supported version 4) before analysis. Correcting the container compiler alone does not correct the analyzer's decoder. The standalone v2.14.0 run is positive compatibility evidence, not a green result for the embedded scanner. Preserve this issue's end-to-end consumer acceptance, all enabled scanners and real-finding rejection; no successful producer/release or local run closes it prematurely.Business-site's separate runtime-link and fictional-database-fixture findings remain distinct. No scanner, finding, protected check or portal feature was disabled.
chore: agent-claim #577 nonce=a8e34f8008f788bb063ccace36bcc9f4
chore: agent-claim #577 nonce=15192ec9b047e135aa1dd72bb27aed54
devantler commentedon Oct 13, 2026
Compiler compatibility acceptance verified. The maintained correction merged in #578 and was published as v7.10.2; its urgent legacy mirror merged in actions#1414 and was published as v13.10.11. The action pin, lint rules, read-only projection and credential boundaries were preserved.
Fresh post-merge maintained CI 38377141567 at
8ed2071ebe18864b8b86efe0f6b1df8d73d2a6abpasses all native validation. I collected all 248 jobs. Its Go 1.26.9 clean fixture actually installs and executes golangci-lint v2.14.0. Its Go 1.27 finding fixture rejects the deliberate errcheck violation, and the log confirms genuine finding rejection rather than an installation failure. Required toolchain guards pass. Independently regenerating the read-only projection from immutable source at that revision produced byte-identical output.Actual consumer acceptance now passes in business-site required run 38391431939, on exact merged PR #70 head
2a112cdb067813778f537794baa9ae6ab792ab88. Both standalone lint and MegaLinter use Go 1.27.2 and complete real analysis. MegaLinter retains its rules and project scope through the supported executable override to v2.14.0; its descriptive v2.13.2 label is not the executed command. The complete 12-job required run succeeds, including Test and race Coverage. No scanner was disabled, finding suppressed, test skipped or protection changed by this verification.This supersedes the earlier incomplete consumer-compatibility checkpoint and completes #577. Root-configuration acceptance in #579 and the PostgreSQL rollout in #573 retain their separate criteria and remain open. No production intake, payment or execution is enabled.
chore: agent-claim #577 nonce=e00bb066b42b88a8e1ee1e8a12edeb2b
chore: agent-claim #577 nonce=4635687873587eff4a3f1310f397c5be