Skip to content

bump golangci-lint#162

Merged
kcp-ci-bot merged 1 commit intokcp-dev:mainfrom
xrstf:bump-golangci-lint
Feb 25, 2026
Merged

bump golangci-lint#162
kcp-ci-bot merged 1 commit intokcp-dev:mainfrom
xrstf:bump-golangci-lint

Conversation

@xrstf
Copy link
Copy Markdown
Contributor

@xrstf xrstf commented Feb 25, 2026

Summary

I ran into issues when running make lint with Go 1.26 installed. Suddenly golangci-lint would just panic with an error saying that Go 1.26 would be required. It's confusing because none of the files in this repo require Go 1.26. 🤷

Unfortunately, the new version of golangci-lint produces a lot of .... less than helpful prealloc messages:

_tools/golangci-lint-2.10.1 run --timeout 10m
internal/controller/frontproxy/controller.go:127:3: Consider preallocating conditions with capacity 1 (prealloc)
                conditions []metav1.Condition
                ^
internal/controller/rootshard/controller.go:70:7: Consider preallocating requests with capacity 1 (prealloc)
                var requests []reconcile.Request
                    ^
internal/controller/shard/controller.go:136:3: Consider preallocating conditions with capacity 1 (prealloc)
                conditions []metav1.Condition
                ^
internal/resources/cacheserver/deployment.go:97:4: Consider preallocating volumes with capacity 1 + len(secretMounts) (prealloc)
                        volumes := []corev1.Volume{{
                        ^
internal/resources/cacheserver/deployment.go:103:4: Consider preallocating volumeMounts with capacity 1 + len(secretMounts) (prealloc)
                        volumeMounts := []corev1.VolumeMount{{
                        ^
internal/resources/cacheserver/deployment.go:192:2: Consider preallocating args (prealloc)
        args := []string{
        ^
internal/resources/rootshard/deployment.go:160:4: Consider preallocating volumes with capacity len(secretMounts) (prealloc)
                        volumes := []corev1.Volume{}
                        ^
internal/resources/rootshard/deployment.go:161:4: Consider preallocating volumeMounts with capacity len(secretMounts) (prealloc)
                        volumeMounts := []corev1.VolumeMount{}
                        ^
internal/resources/shard/deployment.go:137:4: Consider preallocating volumes with capacity len(secretMounts) (prealloc)
                        volumes := []corev1.Volume{}
                        ^
internal/resources/shard/deployment.go:138:4: Consider preallocating volumeMounts with capacity len(secretMounts) (prealloc)
                        volumeMounts := []corev1.VolumeMount{}
                        ^
internal/resources/utils/authentication.go:87:2: Consider preallocating volumes (prealloc)
        volumes := []corev1.Volume{}
        ^
internal/resources/utils/authentication.go:88:2: Consider preallocating volumeMounts (prealloc)
        volumeMounts := []corev1.VolumeMount{}
        ^
internal/resources/utils/authentication.go:127:2: Consider preallocating extraArgs (prealloc)
        extraArgs := []string{}
        ^
13 issues:

And I have a few things to say about these.

  • Suggesting to prealloc a slice with 1 element... come on, linter, just think one more step ahead. If we really wanted to have a 1-element slice, what good is the slice? That is to say, if we actually begin to hardcode conditions := make([]condition, 0, 1), then the entire reconciler is hardcoded to expect 1 condition only. So why would we even use a slice here? On the other hand, if we ever add more conditions, I would bet few people (not including me) would even remember to look at the make() call and adjust it accordingly. Having a slice be pre-allocated to 1 element is just IMHO pure nonsense.
  • The other suggestions are IMHO equally not helpful, like suggesting to prealloc something to 1 + len(secretMounts): Every code change in that reconciler would break the preallocation and require more changes.

If there was an option on the linter to prevent it from complaining about this sort of stuff, I would love to keep the linter enabled. But in its current form, I fear that AI-driven folks will just blindly follow the recommendations and create hard-to-extend, easy-to-break code, just for the sake of PeRfOrMaNcE (let's not even discuss the real world performance implications of dealing with a massive ... 6-element slice in Go... just think of the nanoseconds we could be saving here!).

What Type of PR Is This?

/kind chore

Release Notes

NONE

@xrstf
bump golangci-lint
a87278b 
On-behalf-of: @SAP christoph.mewes@sap.com
@kcp-ci-bot kcp-ci-bot added release-note-none Denotes a PR that doesn't merit a release note. kind/chore Categorizes issue or PR as related to maintenance and other usually non-code changes. dco-signoff: yes Indicates the PR's author has signed the DCO. size/S Denotes a PR that changes 10-29 lines, ignoring generated files. labels Feb 25, 2026
@ntnn
Copy link
Copy Markdown
Member

ntnn commented Feb 25, 2026

/lgtm
/approve

@kcp-ci-bot kcp-ci-bot added the lgtm Indicates that a PR is ready to be merged. label Feb 25, 2026
@kcp-ci-bot
Copy link
Copy Markdown
Contributor

kcp-ci-bot commented Feb 25, 2026

LGTM label has been added.

DetailsGit tree hash: 14fdc28a17a374b93f5c7ec01e41fae5ed1ad057

@xrstf
Copy link
Copy Markdown
Contributor Author

xrstf commented Feb 25, 2026

/approve

@kcp-ci-bot
Copy link
Copy Markdown
Contributor

kcp-ci-bot commented Feb 25, 2026

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: ntnn, xrstf

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Details Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@kcp-ci-bot kcp-ci-bot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Feb 25, 2026
@kcp-ci-bot kcp-ci-bot merged commit 397f1af into kcp-dev:main Feb 25, 2026
11 of 12 checks passed
@xrstf xrstf deleted the bump-golangci-lint branch February 25, 2026 13:03
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

@ntnn ntnn

Labels

approved Indicates a PR has been approved by an approver from all required OWNERS files. dco-signoff: yes Indicates the PR's author has signed the DCO. kind/chore Categorizes issue or PR as related to maintenance and other usually non-code changes. lgtm Indicates that a PR is ready to be merged. release-note-none Denotes a PR that doesn't merit a release note. size/S Denotes a PR that changes 10-29 lines, ignoring generated files.

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

3 participants

@xrstf @ntnn @kcp-ci-bot