Repository navigation
Conversation
…lint The check that Go 1.26 needs golangci-lint 2.9.0 compared two numbers that were written in the script, so each new Go minor version needed a new edit. golangci-lint reports the Go that built it, so compare the toolchain with that instead. The same release is accepted, and nothing has to change for the next Go version. A build that does not report a Go version only logs a warning. Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0127vQEN9nqyQU9EHG8T81wf
The Go support check parsed the toolchain version with parse_version, so a development toolchain passed the check without a comparison, and a prerelease printed printf errors. Read the major and minor version of the toolchain with a pattern instead, and warn and continue when there is none. Also send the warning for an unreadable golangci-lint build to stderr, so that it does not mix into the output of golangci-lint. Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0127vQEN9nqyQU9EHG8T81wf
…ne only Anchor the Go version of golangci-lint on the golangci-lint version line and print the first match only, so that other output, or a second line, cannot change the result. Document in go.sh that golangci_lint_supports_go needs version.sh, which the calling script sources. Reword the comment in golangci-lint.sh to say that devbase requires this, and not golangci-lint. Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0127vQEN9nqyQU9EHG8T81wf
malept
marked this pull request as ready for review
October 31, 2026 01:43
malept
marked this pull request as draft
October 31, 2026 01:44
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
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.
What this PR does / why we need it
Replace the hardcoded "Go 1.26 and later requires golangci-lint 2.9.0 or later" check in
shell/golangci-lint.shwith a check against the Go version that built the installed golangci-lint, read fromgolangci-lint --version. The wrapper now stops when the Go toolchain is newer than the Go that built golangci-lint. The old check needed a manual edit for each new Go minor version.This is stricter for future Go versions: a Go 1.27 toolchain stops the wrapper until golangci-lint is upgraded to a release built with Go 1.27.
Jira ID
DT-5669
Notes for your reviewers
The result for the old rule is unchanged: Go 1.26 with golangci-lint 2.8.0 still fails and Go 1.26 with 2.9.0 still passes, because 2.9.0 is the first release built with Go 1.26.
If the build Go of golangci-lint or the version of the toolchain can't be read, such as with a development build of Go, the wrapper prints a warning to stderr and continues.
The new block of
golangci-lint.shwas run with stubbed--versionoutput for these cases: same Go, older build, development toolchain, release candidate of a newer minor version, and an unreadable build string. The parser was also run on the real output of a localgolangci-lint --version.golangci_lint_supports_goreturns 1 when the toolchain is newer and 2 when the toolchain version has no major and minor version. It usesparse_versionandhas_minimum_version, so the calling script has to sourceversion.sh. This is documented in the header ofgo.sh.Considered and dismissed review findings
godirective of the module. golangci-lint already checks the module version itself. This check keeps what the old hardcoded check did, which also used the toolchain.go.shuses functions fromversion.shwithout sourcing it. The other files inshell/libdo not source their dependencies either, so the dependency is documented in the header and the calling script sources both files.awk '{print $4}'and the Go version with a pattern, from the same line. The version parsing is unchanged from before, so it stays as is.miseon stdout could shift the parsed fields. This is speculative, and the version field already had the same exposure.Generated by Claude Code