Conversation
A golangci-lint built against Go 1.27 reports four issues on the tree that the currently pinned version never reaches, because it aborts on a typecheck error before any linter runs. Two are govet telling us reflect.Ptr is the old spelling of reflect.Pointer. Two are staticcheck on the deprecated Hooks.Prestart in a test table, annotated the way the non-test use of the same field in checkEventHooks already is. Signed-off-by: Daniel Golle <daniel@makrotopia.org>
ci started failing once setup-go's "stable" moved to Go 1.27, in the same
way it did for go1.26:
panic: file requires newer Go version go1.27 (application built with go1.26)
golangci-lint v2.9.0 is built with go1.26 and cannot read the export data
the newer toolchain writes, so every linter aborts before it runs and the
job reports typecheck errors against files no change has touched. v2.13
is the first series built with go1.27.
Verified against go1.27.1 with the release binaries the action installs:
v2.9.0 fails on this tree with and without the preceding commit, v2.13.2
passes with it and reports only the four issues that commit fixes
without it.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The
lintjob has been failing on every pull request since setup-go'sstablemoved to Go 1.27, in the same way it failed for go1.26 before ce94ed3 bumped the pin. golangci-lint v2.9.0 is built with go1.26 and cannot read the export data the newer toolchain writes, so the type checker bails out before any linter runs and the job reportscould not load export data ... export data version 4 is greater than maximum supported version 2against files that the pull request under test never touched. v2.13 is the first series built with go1.27.Bumping the pin on its own is not enough, which is why this is two commits. A linter that can actually run finds four pre-existing issues that the broken one never reached: two from govet, which wants
reflect.Pointerrather than the oldreflect.Ptrspelling, and two from staticcheck about the deprecatedHooks.Prestartin a test table, annotated the way the non-test use of the same field incheckEventHooksalready is. The first commit fixes those, the second moves the pin, so that the tree is clean at the point the new linter starts being used.Both directions were checked locally against go1.27.1, the toolchain the runner installs, using the release binaries the action downloads rather than a locally built linter, since the whole problem is which Go the linter binary was built with:
So the pin bump alone would leave the job red on the four issues, the source fixes alone would leave it red on the mismatch, and the two together make it green. v2.13.0 and v2.13.2 report the same four issues on the unchanged tree, so this is a property of the series rather than of one patch release, and the pin follows the existing style of naming the minor series rather than an exact patch.
Locally the mismatch shows up either as the
export data versionerrors the CI log carries or aspanic: file requires newer Go version go1.27 (application built with go1.26), which is the same wording the previous bump quoted, one Go release on. Both are the same cause and both were observed here.