fix: bump go version to 1.27.0

[kristina-solovyova]

No description provided.

[github-actions]

Dependency Review

✅ No vulnerabilities or license issues or OpenSSF Scorecard issues found.

OpenSSF Scorecard

Package	Version	Score	Details
gomod/go.yaml.in/yaml/v3	3.0.5	Unknown	Unknown

Scanned Files

• go.mod

[kristina-solovyova]

Warning

This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

• fix: upgrade weka-sign-tool default image #2787
• fix: bump go version to 1.27.0 #2786 👈 (View in Graphite)
• fix: detect compute-blocked drive growth, split per-cause warnings, fix infeasibility binding #2785
• fix: tighten auto-full-drives compute sizing and per-role hugepages admission checks #2780
• fix: refactor the new wekacluster admission validators #2769
• fix: avoid deep-copying nodes, containers, and pods in planner inventory read #2770
• fix: aggregate auto-full-drives planner warnings into one event per condition instead of per node #2768
• docs: document act-as-daemonset mode (OP-345) #2748
• feat: weka-capacity dry-run for auto-full-drives (OP-345) #2747
• feat: admission validators for the capacity planners (OP-345) #2746
• feat: support full-drive wekacluster acting as a daemonset and using all drives (OP-345) #2742
• refactor: share node-eligibility, pod-status and drive-ordering helpers (OP-345) #2745
• main

---

How to use the Graphite Merge Queue

Add the label main-merge-queue to this PR to add it to the merge queue.

You must have a Graphite account in order to use the merge queue. Sign up using this link.

An organization admin has required the Graphite Merge Queue in this repository.

Please do not merge from GitHub as this will restart CI on PRs being processed by the merge queue.

This stack of pull requests is managed by Graphite. Learn more about stacking.

[claude]

Claude finished @kristina-solovyova's task in 2m 17s —— View job

---

Review: bump go version to 1.27.0

• Read the diff vs base branch
• Verify no Go version pin was missed (ran the grep documented in go.mod)
• Check nested pkg/ modules + go-steps-engine submodule
• Verify go.mod / go.sum consistency after the dependency bumps
• Post review

The version bump itself is clean and complete. Two things ride along with it that aren't in the title.

---

What checks out

Ran the grep the go.mod header documents:

grep -rn 'golang:[0-9]\|golang [0-9]\|^go 1\.\|alpine"' --exclude-dir=.git .

Every hit is 1.27.0 — go.mod:14, Dockerfile:3, image.Dockerfile:1, .dagger/src/containers/builders.py:9, .tool-versions:1. No pin missed.

The comment's claim about CI holds too: all eight setup-go steps (build.yaml, package.yaml, run_upgrade_test.yaml) use go-version-file: go.mod, so nothing under .github/workflows needs a bump. The remaining 1.26.0 hits in Makefile:65, build.yaml:177 and the suite tests are envtest/Kubernetes versions — unrelated, correctly left alone.

1. Unexplained go-steps-engine submodule bump (medium)

pkg/go-steps-engine moves dc27ed3f → cb205cf7 in a commit titled "bump go version". That submodule drives reconciliation for every controller in this repo, and the pointer change is invisible to review from here — the diff shows one line.

If it's just the engine bumping its own go directive to stay <= 1.27.0 (which the note you added at go.mod:10-11 says is required), that's a fine thing to bundle — but say so in the PR description so a reader doesn't have to go diff the submodule to find out whether reconciliation behavior changed. If it carries anything else, it belongs in its own PR.

2. Dependency bumps not mentioned anywhere (low)

• go.yaml.in/yaml/v3 3.0.4 → 3.0.5 (indirect, go.mod + go.sum)
• github.com/stretchr/testify 1.11.1 → 1.12.1 — go.sum only; testify isn't in this module's require block at all, so it's arriving through the replaced submodule's test deps, which lines up with the submodule bump above.

Both are almost certainly go mod tidy fallout under the new toolchain rather than deliberate. Nothing wrong with them, but a one-line note in the description keeps a version-bump PR from silently moving dependencies.

3. go.mod:10-11 comment wording (nit)

Left inline — "The nested modules under pkg/ do the same" dangles off the setup-go sentence above it, and nested modules don't read go-version-file. The replace-target constraint you're documenting is the part worth keeping.

Notes on verification

• I could not confirm the nested modules' go directives locally — the pkg/ submodules aren't checked out in this workspace, so the one claim in the new comment I can't independently verify is the <= constraint. CI's build is the check for it.
• golangci-lint isn't version-pinned (golangci-lint-action@v9 resolves it), so a fresh Go minor occasionally outruns the linter's parser. The lint job covers this.
• CI at time of review: 5 passed, 0 failed, the main CI run still in progress. Nothing to act on yet.

Nothing here blocks merge — items 1 and 2 are description fixes, item 3 is cosmetic.
• Branch

[claude]

Nit — "do the same" dangles: line 9 is about setup-go reading go-version-file, and nested modules don't read anything. The constraint you're actually documenting (they're local replace targets built by this toolchain, so their go directive must not exceed this one) is the useful half.

Suggested change

	// The nested modules under pkg/ do the same, so they need no change here either; their own
	// go directive must stay <= this one, since a replace'd module is built by this toolchain.
	// The pkg/ submodules are local `replace` targets built by this same toolchain, so they
	// need no pin of their own here; their `go` directive must stay <= this one.

[claude]

Claude finished @kristina-solovyova's task in 1m 13s —— View job

---

Re-review after force-push

• Re-read the diff vs base
• Identify what changed since my last review
• Check go.mod/go.sum consistency against the new submodule pointer
• Post review

Only one thing is new since my previous review: the pkg/weka-k8s-api submodule now moves too (6abf60b5 → 9d0ebfaa). Everything I checked last time still holds — all five Go pins are 1.27.0, no pin missed, setup-go steps all read go-version-file: go.mod.

---

1. Second unexplained submodule bump (medium)

The PR now carries two submodule pointer moves in a commit titled "bump go version":

submodule	from	to
pkg/go-steps-engine	dc27ed3f	cb205cf7
pkg/weka-k8s-api	6abf60b5	9d0ebfaa

Both are local replace targets (go.mod:62, go.mod:64) pinned at v0.0.0, so a pointer move changes no version string here — it silently swaps compiled source. weka-k8s-api is the API types module every CRD in this repo is built from; a pointer change there is invisible from this diff.

I could not inspect either range: the submodules aren't checked out in this workspace, and I don't have permission to query the sibling repos from here. So this is the one claim I can't verify — please state in the PR description what each bump contains. If they're just the engines raising their own go directive to track 1.27.0 (the constraint your new go.mod:10-11 comment documents), bundling them is fine and a one-line note settles it. If either carries behavior changes to reconciliation or API types, it belongs in its own PR.

2. go.sum was not re-tidied alongside the new submodule bump (low)

go.sum in this push is byte-identical to the previous one — still just testify 1.11.1 → 1.12.1 and go.yaml.in/yaml/v3 3.0.4 → 3.0.5, both of which I attributed last time to the go-steps-engine bump. Adding weka-k8s-api to the commit moved no dependency lines at all.

That's consistent and fine if 9d0ebfaa didn't touch its require block. If it did add or bump anything, go mod tidy wasn't rerun and the build fails on a missing go.sum entry. The CI run (still in progress) is the check — worth confirming it goes green before merge rather than assuming.

3. go.mod:10-11 comment wording (nit, unchanged)

Still standing from last review — see the inline suggestion. "The nested modules under pkg/ do the same" dangles off the setup-go sentence, and nested modules don't read go-version-file; the replace-target constraint is the half worth keeping. Fix this →

---

CI at time of review

3 passed, 0 failed, 2 in progress (CI, and this review job). Nothing failing to act on.

The version bump itself remains clean. Items 1 and 2 are description/verification asks rather than code defects, and item 3 is cosmetic — nothing here blocks merge once CI is green.

Branch •

[claude]

Claude finished @kristina-solovyova's task in 1m 11s —— View job

---

Re-review after force-push

• Diff the current push vs base
• Isolate what's new since my 18:53 review
• Check the golangci-lint bump against the repo's lint config and local-dev paths
• Re-check CI

One thing is new since my last review: golangci-lint moves v2.9.0 → v2.13.2 in .github/workflows/build.yaml:54. Everything else — five Go pins at 1.27.0, both submodule pointers, the two go.sum lines — is byte-identical to the push I already reviewed, so I won't repeat those items. (Correction to my last review: I wrote that golangci-lint "isn't version-pinned." It is, at build.yaml:54, and this push is what bumps it.)

The bump itself is right and necessary — golangci-lint embeds the Go parser it was built against, and a v2.9-era binary can't parse 1.27 source. only-new-issues: true keeps the four-minor linter jump from flooding the PR with findings on untouched code.

---

1. The sync-list comment this PR adds is already wrong (medium)

go.mod:9 says:

// GitHub Actions needs no change: every setup-go step reads go-version-file: go.mod.

…in the same commit that changes a GitHub Actions file. The setup-go half is still true, but the takeaway a reader draws — "skip .github/workflows on the next bump" — is now false, and this push is the counter-example.

The documented escape hatch doesn't cover it either. The grep at go.mod:13:

grep -rn 'golang:[0-9]\|golang [0-9]\|^go 1\.\|alpine"' --exclude-dir=.git .

matches none of version: v2.13.2, golangci-lint-action@v9. I re-ran it on the current tree to confirm — five hits, all Go pins, no linter. So the next person bumping Go follows the note, follows the grep, and ships a linter that can't parse the new language version. The whole point of that comment block is to make the next bump mechanical; this is the one pin it now actively steers you away from.

Worth adding golangci-lint to the list as a Go-coupled pin. Fix this →

2. Local make lint isn't pinned to the new linter (low)

Makefile:146 and .pre-commit-config.yaml:6 both invoke a bare golangci-lint from PATH, and .tool-versions pins golang, kubectl, kubebuilder, kind, k9s, operator-sdk, minikube, eksctl, krew, packer — but not golangci-lint. CI is now on v2.13.2 while a developer's asdf-managed shim stays on whatever they installed, which for anyone on a v2.9-era binary means make lint fails to parse 1.27 source locally while CI passes.

Pre-existing gap, but the version skew only starts biting now that CI has moved. A golangci-lint 2.13.2 line in .tool-versions closes it and gives the sync list from item 1 a natural home for the pin. Fix this →

3. go.mod:10-11 comment wording (nit, unchanged)

Still standing from my last two reviews — see the inline suggestion. Folds naturally into the item 1 rewrite.

---

Carried over, unchanged

Both still open from the previous review, both description asks rather than code defects — the two submodule pointer moves (pkg/go-steps-engine dc27ed3f→cb205cf7, pkg/weka-k8s-api 6abf60b5→9d0ebfaa) are still unexplained in a commit titled "bump go version", and go.sum still moves only testify and go.yaml.in/yaml/v3. I still can't inspect either submodule range from this workspace — they aren't checked out here.

CI

3 passed, 0 failed, 2 in progress (CI, and this review job). The CI run is what covers both the go.sum/submodule consistency question and whether v2.13.2's newer linters find anything on the changed lines — worth letting it go green rather than assuming.

Nothing here blocks merge. Item 1 is the one I'd actually fix before merging: it's a two-line edit, and it's in the comment block whose entire purpose is to make the next bump correct.

Branch •

[claude]

Claude finished @kristina-solovyova's task in 41s —— View job

---

Re-review after force-push — no changes to review

• Diff the current push vs base
• Compare against the push I reviewed at 19:09
• Check CI

The diff against 09-01-fix_detect_compute-blocked_drive_growth_split_per-cause_warnings_fix_infeasibility_binding is byte-identical to the push I reviewed at 19:09 — same five Go pins at 1.27.0, same golangci-lint v2.9.0 → v2.13.2, same two submodule pointers, same two go.sum lines, same go.mod comment block. This synchronize looks like a restack, not a content change. Nothing new to review, so I won't repeat the analysis.

Still open from that review

1. (medium) The sync-list comment at go.mod:9 says "GitHub Actions needs no change" in the same commit that bumps golangci-lint in .github/workflows/build.yaml:54, and the documented grep at go.mod:13 doesn't match that pin either — so the next Go bump gets steered past it. Fix this →
2. (low) golangci-lint isn't in .tool-versions, so local make lint (Makefile:146) and the pre-commit hook can lag CI's v2.13.2 on 1.27 source. Fix this →
3. (low) Two submodule pointer moves (pkg/go-steps-engine dc27ed3f→cb205cf7, pkg/weka-k8s-api 6abf60b5→9d0ebfaa) plus the testify / go.yaml.in/yaml/v3 bumps are still unmentioned in the PR description. Description ask, not a code defect — I still can't inspect either submodule range from this workspace.
4. (nit) go.mod:10-11 wording — inline suggestion, folds into item 1.

CI

5 passed, 0 failed, 2 in progress (CI, and this review job); 2 runs cancelled as superseded by the restack. The CI run is what covers the go.sum/submodule consistency question and whether v2.13.2 finds anything new — worth letting it go green before merging.

Nothing here blocks merge. Item 1 remains the one worth fixing first: it's a two-line edit in the comment block whose whole purpose is making the next bump correct.

Branch •

[graphite-app]

Graphite Automations

"Add anton/matt/sergey/kristina as reviwers on operator PRs" took an action on this PR • (09/02/26)

2 reviewers were added to this PR based on Anton Bykov's automation.