Upgrade go directive to 1.26 - #787
Merged
Merged
Conversation
emmanuelmaduwuba-lyft
force-pushed
the
go-1.26-upgrade
branch
from
September 21, 2026 20:45
4c340bb to
3a7a70f
Compare
DS-11161: Production Infrastructure Go 1.26 fleet upgrade. - go.mod go directive: 1.25 -> 1.26 (bare, matching this repo's own precedent -- #775's Go 1.24 bump used `go 1.24`, not `1.24.0`). - .github/workflows/{lint,test}.yml: actions/setup-go go-version 1.25 -> 1.26; golangci-lint-action pinned version v2.4.0 -> v2.13.0 (the old release was built with go1.25 and refused to lint a go1.26-targeted module). That golangci-lint jump crosses the exact release range where gosec shipped a brand-new taint-analysis engine (v2.22.1 -> v2.28.0, engine added in v2.23.0) -- unavoidable, since v2.10.0 is both the first golangci-lint release after Go 1.26 itself existed and the release where the engine landed. It surfaced 13 real findings the old linter couldn't see. Resolved each: - 3x G118 (goroutines using context.Background(), comment.go/ pull_request.go/pull_request_review.go): false positive, each already has an inline comment explaining this is deliberate (parent doesn't wait for the goroutine). nolint referencing it. - 1x G118 (server.go cancel func): false positive, cancel is stored as CancelWorker, not dropped. - 1x G602 (cmd/server.go slice index): false positive, guarded by len(deprecatedFlags) == 1 in the same branch. - 2x G703 (path traversal, git_cred_writer.go): false positive, filename is always a trusted home-dir + hardcoded literal -- matches this file's own existing nolint precedent on the paired os.ReadFile calls. - 4x G705 (XSS, respond/logAndWriteBody helpers across 4 controllers): real fix applied -- explicitly set Content-Type: text/plain before writing (the standard mitigation for content-sniffing-based XSS), then nolint since gosec's static taint check can't see that header-based mitigation. - G101 (hardcoded creds, test fixtures): added a path-based exclusion rule to .golangci.yml for _test.go files and fixtures.go, matching the identical rule already in upstream runatlantis/atlantis's .golangci.yml for the same false-positive class. Verified: go mod tidy, go build ./..., go vet ./..., go test -run '^$' ./... (compile-only), and golangci-lint v2.13.0 (matching CI, --max-same-issues 0) all clean.
emmanuelmaduwuba-lyft
force-pushed
the
go-1.26-upgrade
branch
from
September 22, 2026 01:00
3a7a70f to
e1002eb
Compare
yusyuan-lyft
approved these changes
Sep 22, 2026
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.
Summary
godirective ingo.modfrom1.25to1.26(bare, matching this repo's own precedent —#775's Go 1.24 bump usedgo 1.24, not1.24.0).golangci-lint-action's pinned version (v2.4.0→v2.13.0) andactions/setup-go'sgo-version(1.25→1.26) inlint.yml/test.yml— the old golangci-lint release was built with go1.25 and refused to run against a go1.26-targeted module.Why this needed more than a version bump: the golangci-lint jump (
v2.4.0→v2.13.0) crosses the exact release range where gosec shipped a brand-new taint-analysis engine (securego/gosecv2.22.1→v2.28.0, engine added inv2.23.0). That engine surfaced 13 real findings that the old linter simply couldn't see — this wasn't avoidable by picking a different golangci-lint version:v2.10.0(the first release after Go 1.26 itself existed, so the first one plausibly able to lint go1.26 code) is the same release where the taint engine landed. Resolved each finding individually:G118(goroutines usingcontext.Background()) — false positive; each already has an inline comment explaining this is deliberate (parent doesn't wait for the goroutine). Addednolintreferencing it.G118(server.go, cancel func) — false positive;cancelis stored asCancelWorkerbelow, not dropped.G602(cmd/server.goslice index) — false positive; guarded bylen(deprecatedFlags) == 1in the same branch.G703(path traversal,git_cred_writer.go) — false positive;filenameis always a trusted home-dir + hardcoded literal, matching this file's own existingnolintprecedent on the pairedos.ReadFilecalls.G705(XSS,respond/logAndWriteBodyhelpers across 4 controllers) — real hardening applied: explicitly setContent-Type: text/plainbefore writing (the standard mitigation for content-sniffing-based XSS), thennolintsince gosec's static taint check can't see that header-based mitigation..golangci.ymlfor_test.gofiles andfixtures.go, matching the identical rule already in upstreamrunatlantis/atlantis's.golangci.ymlfor the same false-positive class.Test plan
go mod tidy— cleango build ./...— cleango vet ./...— cleango test -run '^$' ./...— compiles all test binaries cleangolangci-lint run --max-same-issues 0(v2.13.0, matching CI) — 0 issues