build: upgrade to Go 1.26.5 - #521
Conversation
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
WalkthroughThis PR updates Go and CI tool versions, removes configured govulncheck suppressions, revises Make-based generation tool installation, and moves Go formatting logic into ChangesGo toolchain and CI updates
Estimated code review effort: 3 (Moderate) | ~20 minutes Possibly related PRs
Suggested labels: Suggested reviewers: 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
coderabbitai
Bot
added
agentic
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 3
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@go.mod`:
- Around line 7-12: Update the generator configuration used by make generate to
define CRD_REF_DOCS, pin the crd-ref-docs installation version, and remove the
unused CONTROLLER_TOOLS_VERSION setting. Remove the obsolete k8s.io/gengo/v2
dependency and any related go-bindata/gengo references, while pinning every
remaining generator version.
- Around line 3-5: Align all Go toolchain declarations with Go 1.26: update the
root go.mod lines 3-5, README.md line 10, and the go.mod files for
toolchain-common, host-operator, and toolchain-e2e to use the Go 1.26
requirements and toolchain version. Also update required_tools.adoc accordingly,
or explicitly configure and document the required GOTOOLCHAIN switching behavior
if any module must retain older declarations.
In `@make/generate.mk`:
- Around line 18-27: Define CRD_REF_DOCS alongside the other generator binary
variables so it resolves under LOCALBIN, then update the CRD_REF_DOCS
installation rule to install a fixed crd-ref-docs version instead of `@latest`.
Preserve the existing controller-gen and openapi-gen version behavior.
🪄 Autofix
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Enterprise
Run ID: d47d26f8-ea1f-47bc-b4af-637b65bc333a
⛔ Files ignored due to path filters (1)
go.sumis excluded by!**/*.sum
📒 Files selected for processing (25)
.claude/commands/commit-with-message.md.github/workflows/ci-build.yml.govulncheck.yamlREADME.adocREADME.mdapi/v1alpha1/banneduser_types.goapi/v1alpha1/idler_types.goapi/v1alpha1/masteruserrecord_types.goapi/v1alpha1/memberstatus_types.goapi/v1alpha1/notification_types.goapi/v1alpha1/nstemplateset_types.goapi/v1alpha1/nstemplatetier_types.goapi/v1alpha1/proxyplugin_types.goapi/v1alpha1/socialevent_types.goapi/v1alpha1/toolchainstatus_types.goapi/v1alpha1/useraccount_types.goapi/v1alpha1/usersignup_types.goapi/v1alpha1/usertier_types.gocmd/manager/main.gogo.modmake/format.mkmake/generate.mkmake/go.mkmake/gofmt_excludetools.go
🔗 Linked repositories identified
CodeRabbit considers these linked repositories for cross-repo context during reviews:
codeready-toolchain/api(manual)codeready-toolchain/toolchain-common(manual)codeready-toolchain/host-operator(manual)codeready-toolchain/toolchain-e2e(manual)
💤 Files with no reviewable changes (5)
- tools.go
- README.adoc
- .govulncheck.yaml
- cmd/manager/main.go
- make/format.mk
📜 Review details
⏰ Context from checks skipped due to timeout. (1)
- GitHub Check: Verify Dependencies
🧰 Additional context used
📓 Path-based instructions (1)
**
⚙️ CodeRabbit configuration file
-Focus on major issues impacting performance, readability, maintainability and security. Avoid nitpicks and avoid verbosity.
Files:
api/v1alpha1/nstemplatetier_types.goapi/v1alpha1/nstemplateset_types.gomake/go.mkmake/gofmt_excludego.modapi/v1alpha1/notification_types.goapi/v1alpha1/toolchainstatus_types.goREADME.mdapi/v1alpha1/memberstatus_types.goapi/v1alpha1/socialevent_types.goapi/v1alpha1/proxyplugin_types.goapi/v1alpha1/banneduser_types.goapi/v1alpha1/usersignup_types.goapi/v1alpha1/masteruserrecord_types.goapi/v1alpha1/useraccount_types.goapi/v1alpha1/idler_types.goapi/v1alpha1/usertier_types.gomake/generate.mk
🪛 LanguageTool
README.md
[style] ~26-~26: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.
Context: ...enerate zz_generated.openapi.go. 3. Generate API reference docs — uses [crd-ref-do...
(ENGLISH_WORD_REPEAT_BEGINNING_RULE)
🪛 markdownlint-cli2 (0.23.2)
README.md
[warning] 6-6: Link text should be descriptive
(MD059, descriptive-link-text)
[warning] 10-10: Link text should be descriptive
(MD059, descriptive-link-text)
[warning] 30-30: Blank line inside blockquote
(MD028, no-blanks-blockquote)
🪛 zizmor (1.29.0)
.github/workflows/ci-build.yml
[error] 21-21: runtime artifacts potentially vulnerable to a cache poisoning attack (cache-poisoning): enables caching by default
(cache-poisoning)
🔀 Multi-repo context codeready-toolchain/host-operator, codeready-toolchain/toolchain-common, codeready-toolchain/toolchain-e2e
Linked repositories findings
host-operator
- Documentation already instructs contributors to run
make generatefor API and CRD regeneration, matching the changed API workflow. [::codeready-toolchain/host-operator::] go.modremains on Go1.24.4with toolchain1.24.13, while this PR raises the API module to Go1.26.0/toolchain1.26.5. This version constraint should be checked for downstream compatibility. [::codeready-toolchain/host-operator::]
toolchain-common
- Depends directly on
github.com/codeready-toolchain/apiand remains declared for Go1.24.4/toolchain1.24.13; verify whether it can consume the API module after its Go version bump. [::codeready-toolchain/toolchain-common::]
toolchain-e2e
- Directly depends on the API module but remains on Go
1.24.4/toolchain1.24.13. Itsrequired_tools.adocalso requires Go 1.24.x, so the API’s new Go 1.26 requirement may require downstream documentation and CI updates. [::codeready-toolchain/toolchain-e2e::]
🔇 Additional comments (20)
.claude/commands/commit-with-message.md (1)
1-25: LGTM!.github/workflows/ci-build.yml (1)
21-21: 🩺 Stability & AvailabilityKeep
actions/setup-go@v7. Thev7tag exists, so this reference is available. No change is needed.> Likely an incorrect or invalid review comment.go.mod (1)
40-46: LGTM!make/gofmt_exclude (1)
1-1: LGTM!README.md (1)
1-9: LGTM!Also applies to: 11-31
api/v1alpha1/banneduser_types.go (1)
23-23: LGTM!api/v1alpha1/idler_types.go (1)
26-26: LGTM!Also applies to: 36-36
api/v1alpha1/masteruserrecord_types.go (1)
51-51: LGTM!Also applies to: 86-86
api/v1alpha1/useraccount_types.go (1)
41-41: LGTM!Also applies to: 58-58
api/v1alpha1/usersignup_types.go (1)
215-215: LGTM!Also applies to: 284-284
api/v1alpha1/usertier_types.go (1)
24-24: LGTM!make/generate.mk (1)
29-56: LGTM!Also applies to: 70-72, 95-117
make/go.mk (1)
11-17: LGTM!Also applies to: 27-27
api/v1alpha1/memberstatus_types.go (1)
12-12: LGTM!Also applies to: 21-21, 81-81, 96-96
api/v1alpha1/notification_types.go (1)
40-40: LGTM!Also applies to: 75-75
api/v1alpha1/nstemplateset_types.go (1)
38-38: LGTM!api/v1alpha1/nstemplatetier_types.go (1)
19-19: LGTM!Also applies to: 89-89
api/v1alpha1/proxyplugin_types.go (1)
14-14: LGTM!Also applies to: 28-28
api/v1alpha1/socialevent_types.go (1)
25-25: LGTM!Also applies to: 62-62
api/v1alpha1/toolchainstatus_types.go (1)
59-59: LGTM!Also applies to: 68-68, 122-122, 150-150
| go 1.26.0 | ||
|
|
||
| toolchain go1.24.13 | ||
| toolchain go1.26.5 |
There was a problem hiding this comment.
🗄️ Data Integrity & Integration | 🟠 Major | 🏗️ Heavy lift
🧩 Analysis chain
🏁 Script executed:
set -eu
printf '%s\n' '--- api go.mod ---'
cat -n go.mod | sed -n '1,20p'
printf '%s\n' '--- api README prerequisite lines ---'
rg -n -C 2 'Go version|1\.24|1\.26|toolchain' README.md .github Makefile* 2>/dev/null || true
printf '%s\n' '--- api workflow/toolchain references ---'
rg -n -i 'go-version|setup-go|1\.24|1\.26|toolchain' .github Makefile* 2>/dev/null || trueRepository: codeready-toolchain/api
Length of output: 3860
🏁 Script executed:
set -eu
printf '%s\n' '--- toolchain-common go.mod ---'
cat -n go.mod | sed -n '1,15p'
printf '%s\n' '--- toolchain-common Go CI references ---'
rg -n -i 'go-version|setup-go|1\.24|1\.26|toolchain' .github Makefile* 2>/dev/null || true
printf '%s\n' '--- api dependency references ---'
rg -n 'codeready-toolchain/api|replace .*api' go.mod go.sum .github Makefile* 2>/dev/null || trueRepository: codeready-toolchain/toolchain-common
Length of output: 1919
🏁 Script executed:
set -eu
printf '%s\n' '--- host-operator go.mod ---'
cat -n go.mod | sed -n '1,15p'
printf '%s\n' '--- host-operator Go CI references ---'
rg -n -i 'go-version|setup-go|1\.24|1\.26|toolchain' .github Makefile* 2>/dev/null || true
printf '%s\n' '--- api dependency references ---'
rg -n 'codeready-toolchain/api|replace .*api' go.mod go.sum .github Makefile* 2>/dev/null || trueRepository: codeready-toolchain/host-operator
Length of output: 3435
🏁 Script executed:
set -eu
printf '%s\n' '--- toolchain-e2e go.mod ---'
cat -n go.mod | sed -n '1,15p'
printf '%s\n' '--- toolchain-e2e Go CI and documentation references ---'
rg -n -i 'go-version|setup-go|1\.24|1\.26|toolchain' .github Makefile* required_tools.adoc 2>/dev/null || true
printf '%s\n' '--- api dependency references ---'
rg -n 'codeready-toolchain/api|replace .*api' go.mod go.sum .github Makefile* 2>/dev/null || trueRepository: codeready-toolchain/toolchain-e2e
Length of output: 2730
🌐 Web query:
Go toolchain selection behavior when a dependency module's go.mod requires a newer Go version than the main module, and whether Go 1.24 automatically switches for that dependency
💡 Result:
In Go, the toolchain selection behavior is determined by the configuration in the main module's go.mod file (or go.work file in a workspace) and the GOTOOLCHAIN environment variable [1][2]. When a dependency module requires a newer Go version than the main module, the go command does not automatically switch toolchains based on the dependency's requirements alone [1][3]. Instead, it enforces compatibility constraints [3][4]. The specific behaviors are as follows: 1. Mandatory Version Requirement: Since Go 1.21, the go directive in a go.mod file is a mandatory requirement [3][2]. A Go toolchain will refuse to build a module if it requires a Go version newer than what the current toolchain supports [2][5]. If a dependency requires a newer Go version, the current (older) toolchain will typically fail during the dependency resolution or build process because it cannot satisfy the requirement [2][4]. 2. Automatic Toolchain Switching: If GOTOOLCHAIN is set to auto (the default) or path, the go command can automatically download and switch to a newer toolchain [1][4]. However, this switching is governed by the go and toolchain directives in the main module’s go.mod (or go.work), not by the requirements of indirect dependencies [1][5]. The main module must explicitly indicate that a newer toolchain is required [1][4]. 3. Updating for Dependencies: When you add or update a dependency that requires a newer Go version, commands like go get will typically notice the new requirement and update the main module's go.mod file—specifically the go line and the toolchain line—to match the requirements of the dependency [1][4]. This ensures that future invocations of the go command use an appropriate toolchain that satisfies the new dependency's minimum Go version [1]. 4. Go 1.24 and Newer: Go 1.24 does not introduce a mechanism to "automatically switch" to a newer toolchain purely because a dependency happens to require it without those requirements being reflected in the main module [6]. The fundamental rule remains: the main module's go.mod dictates the environment [1]. Go 1.24 continues to rely on the main module's go and toolchain directives to determine if an upgrade is necessary, and it ensures that the toolchain selected is capable of building the entire dependency graph [1][6]. If you are working in a module that does not have its go or toolchain lines updated to a version capable of supporting your newer dependencies, the build will fail [2][4]. In summary, Go toolchain switching is a top-down process driven by the main module's configuration. Dependencies do not trigger automatic toolchain switching; rather, commands like go get update the main module to support the dependencies, which subsequently allows the go command to select the correct toolchain for future operations [1][4].
Citations:
- 1: https://go.dev/doc/toolchain
- 2: https://go.dev/blog/toolchain
- 3: https://go.dev/ref/mod
- 4: https://go.googlesource.com/website/+/refs/heads/master/_content/doc/toolchain.md
- 5: https://go.dev/doc/modules/gomod-ref
- 6: cmd/go: "get -tool" should fail if toolchain is below 1.24 in go.mod golang/go#74739
🏁 Script executed:
set -eu
printf '%s\n' '--- host-operator Go directives ---'
rg -n -C 2 '^(go|toolchain) ' go.mod
printf '%s\n' '--- host-operator setup-go workflow sections ---'
rg -n -A 5 -B 3 'go-version-file|setup-go' .github/workflowsRepository: codeready-toolchain/host-operator
Length of output: 3827
🏁 Script executed:
set -eu
printf '%s\n' '--- toolchain-common Go directives ---'
rg -n -C 2 '^(go|toolchain) ' go.mod
printf '%s\n' '--- toolchain-common setup-go workflow sections ---'
rg -n -A 5 -B 3 'go-version-file|setup-go' .github/workflowsRepository: codeready-toolchain/toolchain-common
Length of output: 2476
🏁 Script executed:
set -eu
printf '%s\n' '--- toolchain-e2e Go directives ---'
rg -n -C 2 '^(go|toolchain) ' go.mod
printf '%s\n' '--- toolchain-e2e setup-go workflow sections ---'
rg -n -A 5 -B 3 'go-version-file|setup-go' .github/workflowsRepository: codeready-toolchain/toolchain-e2e
Length of output: 2390
🏁 Script executed:
set -eu
python3 - <<'PY'
from pathlib import Path
import re
repos = {
"api": Path("go.mod"),
"toolchain-common": Path("../toolchain-common/go.mod"),
"host-operator": Path("../host-operator/go.mod"),
"toolchain-e2e": Path("../toolchain-e2e/go.mod"),
}
for name, path in repos.items():
text = path.read_text()
directives = dict(re.findall(r"(?m)^(go|toolchain)\s+(\S+)", text))
print(name, directives)
PYRepository: codeready-toolchain/api
Length of output: 745
🌐 Web query:
site:go.dev/doc/toolchain dependency go.mod requires newer Go version automatic toolchain switching
💡 Result:
The Go toolchain includes an automatic switching mechanism that ensures compatibility when a project requires a newer Go version than the one currently installed [1]. When you run a Go command in a main module that specifies a higher Go version in its go.mod file than the currently installed Go toolchain, the Go command automatically attempts to resolve this discrepancy [1]. If automatic switching is permitted by the GOTOOLCHAIN configuration (which defaults to 'auto'), the command will look for a newer version of the toolchain, first checking the system PATH for a specifically named binary (e.g., go1.21.9) and otherwise downloading and caching the required version [1]. Key points regarding this behavior include: 1. Toolchain Directive: The go.mod file contains a go directive that specifies the minimum required Go version [1]. Additionally, a toolchain directive may be present to explicitly record the toolchain name used, which helps maintain repeatability [1]. 2. Version Resolution: If the version specified in the go.mod file is newer than the bundled toolchain, the Go command automatically switches to the newer version to execute the command [1]. 3. Configuration: This behavior is controlled by the GOTOOLCHAIN environment variable. If automatic switching is disabled, the Go command will refuse to run if the required version exceeds the bundled version, requiring a manual update [1]. 4. Updates: When commands (such as go get) update the module requirements to a version needing a newer Go release, they automatically update the go and toolchain lines in the go.mod or go.work file to reflect the new requirements [1].
Citations:
🏁 Script executed (no clone):
set -eu
python3 - <<'PY'
from urllib.request import urlopen
url = "https://go.dev/doc/toolchain"
text = urlopen(url, timeout=20).read().decode()
terms = (
"dependency",
"go.mod file",
"GOTOOLCHAIN",
"automatically switches",
"module graph",
)
for i, line in enumerate(text.splitlines(), 1):
if any(term.lower() in line.lower() for term in terms):
print(f"{i}: {line.strip()}")
PY
Length of output: 2411
🌐 Web query:
site:go.dev/doc/toolchain "dependency" "go.mod" "switch" newer toolchain
💡 Result:
To switch to or specify a newer toolchain in Go, you can use the toolchain directive within your go.mod file [1]. The go.mod file contains a go directive that specifies the minimum required Go version for your module [1]. The toolchain directive, when added to the go.mod file, provides a mechanism to select a specific Go toolchain version that takes precedence over the version specified in the go directive [1]. When you run Go commands (such as go get, go work use, or go install), the Go toolchain may automatically switch to a newer version if your module's requirements demand a newer Go version than your current toolchain provides, provided the GOTOOLCHAIN environment variable is configured to allow automatic switching (e.g., set to auto or path) [1]. When such a switch occurs or when you manually update your environment, Go commands will automatically update the go and toolchain lines in your go.mod file to ensure reproducibility [1]. Specifically, if a command triggers a switch or update, it writes the new minimum Go version requirement to the go.mod file and records the specific toolchain name in the toolchain directive [1]. This ensures that subsequent runs of the go command utilize the specified toolchain version [1].
Citations:
🌐 Web query:
actions/setup-go go-version-file go.mod toolchain directive or go directive behavior
💡 Result:
When using actions/setup-go (v6.0.0 and later) with the go-version-file input set to a go.mod file, the action performs Go version selection by checking both the toolchain and go directives [1][2][3]. The behavior is as follows: 1. Precedence: If the toolchain directive is present in the go.mod file, the action uses the version specified there [1][2][4]. If no toolchain directive exists, it falls back to the version specified in the go directive [2][4][5]. 2. Environment Variable Override: The action respects the GOTOOLCHAIN environment variable [6]. If GOTOOLCHAIN is explicitly set to local, the action ignores the toolchain directive and defaults to the version defined in the go directive [6][7][8]. This behavior ensures alignment with the official Go toolchain selection guidelines, preventing the action from automatically selecting a newer toolchain when restricted to local versions [7][8]. 3. Version Resolution: - If a specific patch version is provided in either directive, the action uses that exact version [2][4]. - If only a major or major.minor version is provided (e.g., go 1.23), the action searches for the latest available patch version in the local cache, the versions-manifest.json file, and finally, the official Go language download site [4][9]. This version selection logic is designed to ensure consistency between the Go environment installed by the action and the requirements defined within the project's dependency files [2][3]. Additionally, when using go.mod for version detection, the action's cache keys automatically incorporate the version detected from these directives to prevent cache conflicts [2][3]. If both go-version and go-version-file inputs are provided, the explicit go-version input takes precedence and overrides the version detected from the go.mod file [1][2][5].
Citations:
- 1: https://github.com/actions/setup-go/blob/main/README.md
- 2: https://github.com/actions/setup-go/tree/v6.1.0
- 3: actions/setup-go@a5f9b05
- 4: https://gitea.rs.h3.ink/actions/setup-go/raw/tag/v7/docs/advanced-usage.md
- 5: https://github.com/actions/setup-go/tree/v6.3.0
- 6: https://github.com/actions/setup-go/blob/main/src/installer.ts
- 7: More specific handling/detection of Go toolchain versions actions/setup-go#457
- 8: Improve toolchain handling actions/setup-go#460
- 9: https://github.com/actions/setup-go/blob/main/docs/advanced-usage.md
🏁 Script executed on all repositories:
set -eu
python3 - <<'PY'
from pathlib import Path
import re
go_mod = Path("go.mod")
if not go_mod.exists():
print("no go.mod")
raise SystemExit(0)
text = go_mod.read_text()
directives = dict(re.findall(r"(?m)^(go|toolchain)\s+(\S+)", text))
api_dep = bool(re.search(r"(?m)^\s*github\.com/codeready-toolchain/api\s+\S+", text))
setup_go = []
for workflow in Path(".github/workflows").glob("*"):
if workflow.is_file():
workflow_text = workflow.read_text(errors="replace")
if "go-version-file: go.mod" in workflow_text:
setup_go.append(str(workflow))
print({
"go_directive": directives.get("go"),
"toolchain_directive": directives.get("toolchain"),
"direct_api_dependency": api_dep,
"setup_go_reads_go_mod": bool(setup_go),
"setup_go_workflows": setup_go,
})
if go_mod.name == "go.mod" and Path("README.md").exists():
readme = Path("README.md").read_text()
matches = [line.strip() for line in readme.splitlines()
if re.search(r"Go version|go 1\.24|Go 1\.24|1\.26", line)]
if matches:
print({"readme_go_lines": matches})
PY
Length of output: 2038
Align all Go toolchain contracts with Go 1.26.
Update README.md, required_tools.adoc, and the go.mod files for toolchain-common, host-operator, and toolchain-e2e. These modules directly require the API module but declare Go 1.24.4 and go1.24.13; their CI reads those declarations with actions/setup-go. Otherwise, explicitly test and document the required GOTOOLCHAIN switching configuration.
📍 Affects 2 files
go.mod#L3-L5(this comment)README.md#L10-L10
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@go.mod` around lines 3 - 5, Align all Go toolchain declarations with Go 1.26:
update the root go.mod lines 3-5, README.md line 10, and the go.mod files for
toolchain-common, host-operator, and toolchain-e2e to use the Go 1.26
requirements and toolchain version. Also update required_tools.adoc accordingly,
or explicitly configure and document the required GOTOOLCHAIN switching behavior
if any module must retain older declarations.
Sources: Path instructions, Linked repositories
| require ( | ||
| github.com/go-bindata/go-bindata v3.1.2+incompatible | ||
| // using latest commit from 'github.com/openshift/api branch release-4.20' | ||
| github.com/openshift/api v0.0.0-20251202204302-1cb53e34ca33 | ||
| k8s.io/api v0.33.4 | ||
| k8s.io/apimachinery v0.33.4 | ||
| k8s.io/code-generator v0.33.4 | ||
| k8s.io/gengo v0.0.0-20230829151522-9cce18d56c01 | ||
| k8s.io/code-generator v0.33.4 // indirect |
There was a problem hiding this comment.
🗄️ Data Integrity & Integration | 🟠 Major | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/usr/bin/env bash
set -euo pipefail
rg -n 'go-bindata|gengo|go install|go run|generate' make go.mod README.mdRepository: codeready-toolchain/api
Length of output: 2200
🏁 Script executed:
#!/usr/bin/env bash
set -euo pipefail
printf '%s\n' '--- make/generate.mk ---'
cat -n make/generate.mk
printf '%s\n' '--- go.mod tool dependencies and references ---'
rg -n -C 3 'go-bindata|gengo|controller-gen|openapi-gen|crd-ref-docs|go install|go run' go.mod make README.md
printf '%s\n' '--- all generation-related make targets and tool definitions ---'
rg -n -C 5 'CONTROLLER_GEN|OPENAPI_GEN|CRD_REF_DOCS|generate|install|download|curl|wget' makeRepository: codeready-toolchain/api
Length of output: 16180
🏁 Script executed:
#!/usr/bin/env bash
set -euo pipefail
printf '%s\n' '--- generator variables and includes ---'
rg -n -C 4 'CRD_REF_DOCS|CONTROLLER_TOOLS_VERSION|generate\.mk|include .*make' Makefile make go.mod
printf '%s\n' '--- repository-wide removed-tool references ---'
rg -n -i 'go-bindata|(^|[^[:alnum:]_/])gengo([^[:alnum:]_/]|$)|k8s\.io/gengo' . --glob '!vendor/**' --glob '!bin/**' || true
printf '%s\n' '--- generator module versions ---'
rg -n 'controller-tools|kube-openapi|crd-ref-docs|gengo' go.mod go.sum 2>/dev/null || true
printf '%s\n' '--- makefile target expansion ---'
make -n -f Makefile generate 2>&1 | sed -n '1,120p'Repository: codeready-toolchain/api
Length of output: 3543
Fix the generator tool transition.
CRD_REF_DOCS is undefined, so make generate cannot invoke crd-ref-docs. The crd-ref-docs installation also uses @latest, and CONTROLLER_TOOLS_VERSION is unused. Define CRD_REF_DOCS and pin every generator version. k8s.io/gengo/v2 remains in go.mod, although no target invokes gengo or go-bindata.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@go.mod` around lines 7 - 12, Update the generator configuration used by make
generate to define CRD_REF_DOCS, pin the crd-ref-docs installation version, and
remove the unused CONTROLLER_TOOLS_VERSION setting. Remove the obsolete
k8s.io/gengo/v2 dependency and any related go-bindata/gengo references, while
pinning every remaining generator version.
Source: Path instructions
| CONTROLLER_TOOLS_VERSION ?= v0.18.0 | ||
|
|
||
| PROJECT_DIR := $(shell pwd) | ||
| $(CONTROLLER_GEN): ## install controller-gen locally if necessary. | ||
| GOBIN=$(LOCALBIN) $(GO) install sigs.k8s.io/controller-tools/cmd/controller-gen | ||
|
|
||
| $(OPENAPI_GEN): ## install openapi-gen locally if necessary. | ||
| GOBIN=$(LOCALBIN) $(GO) install k8s.io/kube-openapi/cmd/openapi-gen | ||
|
|
||
| $(CRD_REF_DOCS): ## install crd-ref-docs locally if necessary. | ||
| GOBIN=$(LOCALBIN) $(GO) install github.com/elastic/crd-ref-docs@latest |
There was a problem hiding this comment.
📐 Maintainability & Code Quality | 🟠 Major | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
rg -n -C2 'CONTROLLER_TOOLS_VERSION|CRD_REF_DOCS|OPENAPI_GEN|go install' \
make/generate.mk go.mod go.sum 2>/dev/null || trueRepository: codeready-toolchain/api
Length of output: 1826
🏁 Script executed:
#!/bin/bash
set -euo pipefail
printf '%s\n' '--- make/generate.mk ---'
cat -n make/generate.mk
printf '%s\n' '--- module and tool references ---'
rg -n -C3 'controller-tools|kube-openapi|crd-ref-docs|CONTROLLER_TOOLS_VERSION|CRD_REF_DOCS|OPENAPI_GEN|CONTROLLER_GEN|generate' \
go.mod go.sum Makefile make .github 2>/dev/null || true
printf '%s\n' '--- tracked generator/config files ---'
git ls-files | rg '(^|/)(generate\.mk|go\.mod|go\.sum|Makefile|.*openapi.*|.*crd.*)' || trueRepository: codeready-toolchain/api
Length of output: 12817
🏁 Script executed:
#!/bin/bash
set -euo pipefail
printf '%s\n' '--- downstream Go versions and API dependency ---'
rg -n -C2 '^(go|toolchain) |github.com/codeready-toolchain/api' go.modRepository: codeready-toolchain/toolchain-common
Length of output: 500
🏁 Script executed:
#!/bin/bash
set -euo pipefail
printf '%s\n' '--- api module declarations ---'
sed -n '1,80p' go.mod
printf '%s\n' '--- generator target dependencies in the repository ---'
rg -n 'controller-gen|openapi-gen|crd-ref-docs|CONTROLLER_TOOLS_VERSION|`@latest`|go install' \
--glob '!vendor/**' --glob '!node_modules/**' . 2>/dev/null || true
printf '%s\n' '--- recent changes for generate.mk ---'
git log --oneline -8 -- make/generate.mkRepository: codeready-toolchain/api
Length of output: 12474
🌐 Web query:
Go command documentation go install package without @Version module-aware behavior and reproducibility
💡 Result:
When using the go install command without a version suffix (e.g., go install example.com/pkg), the behavior is strictly tied to the context of the main module [1][2][3]. In this mode, the command operates within the existing environment defined by the go.mod file in the current directory or its parent directory [1][2]. Key points regarding this behavior and reproducibility include: 1. Context-Dependent Execution: Without a version suffix, go install relies on the module graph, dependency requirements, and directives (such as replace or exclude) specified in the local go.mod file [2][3]. If invoked outside of a module while module-aware mode is enabled, the command will typically report an error [3][4]. 2. Reproducibility: Because this approach respects the versions already locked in your go.mod and go.sum files, it provides consistent, reproducible builds across different environments [2][5]. This is fundamentally different from using a version suffix like @latest, which intentionally ignores the local go.mod file and fetches the latest available version from the module proxy, thereby sacrificing local version pinning [1][2]. 3. Module-Aware Mode: The exact execution mode (module-aware vs. legacy GOPATH mode) is determined by the GO111MODULE environment variable and the presence of a go.mod file [1][6]. In modern Go, module-aware mode is the standard [1][7]. 4. Recommended Practice: For reproducible builds, it is best practice to manage dependencies via the go.mod file and install tools or packages without version suffixes, ensuring they adhere to the project's pinned dependency versions [2][8]. Using @version suffixes is intended specifically for installing tools or executables in a way that is isolated from the current project's dependency graph [1][2]. To ensure full reproducibility (including avoiding host-specific path leaks in binaries), it is recommended to use the -trimpath flag during the build or install process [9].
Citations:
- 1: https://pkg.go.dev/cmd/go
- 2: https://go.dev/doc/go-get-install-deprecation
- 3: https://go.googlesource.com/proposal/+/refs/heads/master/design/40276-go-install.md
- 4: cmd/go: 'go install' should install executables in module mode outside a module golang/go#40276
- 5: https://research.swtch.com/vgo-intro.pdf
- 6: https://pkg.go.dev/cmd/go@go1.26.5
- 7: https://go.dev/ref/mod
- 8: https://github.com/nnnkkk7/gopin
- 9: https://go.dev/blog/rebuild
🏁 Script executed:
#!/bin/bash
set -euo pipefail
printf '%s\n' '--- Makefile and tool declarations ---'
cat -n Makefile
printf '%s\n' '--- tools.go ---'
cat -n tools.go
printf '%s\n' '--- all CRD_REF_DOCS declarations/usages ---'
rg -n -C3 'CRD_REF_DOCS|crd-ref-docs|CONTROLLER_TOOLS_VERSION|controller-tools|kube-openapi' \
--glob '!go.sum' . 2>/dev/null || true
printf '%s\n' '--- relevant commit summaries ---'
git show --stat --oneline b2e67fc 2>/dev/null || true
git show --format=fuller --no-ext-diff --unified=20 b2e67fc -- make/generate.mk tools.go go.mod 2>/dev/null || trueRepository: codeready-toolchain/api
Length of output: 12226
🏁 Script executed (no clone):
#!/bin/bash
set -euo pipefail
printf '%s\n' '--- available crd-ref-docs release tags ---'
git ls-remote --tags --refs https://github.com/elastic/crd-ref-docs.git \
| sed -n 's#.*refs/tags/##p' \
| tail -20
Length of output: 277
🏁 Script executed:
#!/bin/bash
set -euo pipefail
python3 - <<'PY'
from pathlib import Path
import re
mk = Path("make/generate.mk").read_text()
mod = Path("go.mod").read_text()
tools = Path("tools.go").read_text()
for name in ("CONTROLLER_GEN", "OPENAPI_GEN", "CRD_REF_DOCS", "CONTROLLER_TOOLS_VERSION"):
defs = re.findall(rf"(?m)^\s*{name}\s*(?:\?[:]?=|:=|=)", mk)
uses = len(re.findall(rf"\$\({name}\)", mk))
print(f"{name}: definitions={len(defs)}, references={uses}")
for module in (
"sigs.k8s.io/controller-tools",
"k8s.io/kube-openapi",
"github.com/elastic/crd-ref-docs",
):
print(f"{module}: go.mod direct/indirect entries="
f"{len(re.findall(rf'(?m)^\\s*{re.escape(module)}\\s+\\S+', mod))}")
print(f"{module}: tools.go reference={module in tools}")
PY
printf '%s\n' '--- dry-run of the affected target with an isolated minimal Makefile ---'
make -f - -n gen-crd-ref-docs <<'EOF'
CRD_REF_DOCS :=
gen-crd-ref-docs: $(CRD_REF_DOCS)
$(CRD_REF_DOCS) --source-path ./api/v1alpha1
EOFRepository: codeready-toolchain/api
Length of output: 398
🏁 Script executed:
#!/bin/bash
set -euo pipefail
printf '%s\n' '--- Makefile includes and variable definitions ---'
rg -n -C4 'include|CRD_REF_DOCS|LOCALBIN|GO[[:space:]]*[:?+]?=' Makefile make .github 2>/dev/null || true
printf '%s\n' '--- tool module declarations ---'
rg -n -C2 'sigs.k8s.io/controller-tools|k8s.io/kube-openapi|github.com/elastic/crd-ref-docs' \
go.mod tools.go go.sumRepository: codeready-toolchain/api
Length of output: 4833
Define CRD_REF_DOCS and pin crd-ref-docs.
CRD_REF_DOCS is undefined, so make generate cannot run the documentation generator. Define it under LOCALBIN and replace @latest with a fixed version. controller-gen and openapi-gen already use versions selected by go.mod.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@make/generate.mk` around lines 18 - 27, Define CRD_REF_DOCS alongside the
other generator binary variables so it resolves under LOCALBIN, then update the
CRD_REF_DOCS installation rule to install a fixed crd-ref-docs version instead
of `@latest`. Preserve the existing controller-gen and openapi-gen version
behavior.
| # how to dispatch the CRD files per repository (space-separated lists) | ||
| HOST_CLUSTER_CRDS:=masteruserrecords nstemplatetiers usersignups bannedusers notifications spaces spacebindings socialevents tiertemplates tiertemplaterevisions toolchainstatuses toolchainclusters toolchainconfigs usertiers proxyplugins spacerequests spacebindingrequests spaceprovisionerconfigs | ||
| MEMBER_CLUSTER_CRDS:=useraccounts nstemplatesets memberstatuses idlers toolchainclusters memberoperatorconfigs spacerequests workspaces spacebindingrequests | ||
| PROJECT_DIR := $(shell pwd) |
There was a problem hiding this comment.
Is PROJECT_DIR still used?
There was a problem hiding this comment.
Same for API_GROUPNAME and CONTROLLER_TOOLS_VERSION
There was a problem hiding this comment.
these changes are being addressed in #519, I rebase or merge this PR once the former is merged
…nd modernize project docs - Update code generation instructions in API type comments from `"operator-sdk generate k8s"` to `"make generate"` - Delete `cmd/manager/main.go` dummy entrypoint that only existed for `operator-sdk generate csv` - Replace `README.adoc` with `README.md` and update build instructions - Adopt the Kubebuilder v4 pattern for local tool management: - Add `LOCALBIN` and `go-install-tool` helper for version-pinned binaries - Pin `controller-gen` to `v0.18.0`, `operator-sdk` to `v1.42.0` - Split `generate` (DeepCopy code) and `manifests` (CRD/webhook) targets - Regenerate `zz_generated.openapi.go` with updated tooling Assisted-by: Claude Opus 4.6 (1M context) Signed-off-by: Xavier Coulon <xcoulon@redhat.com>
also, remvoed outdated vulnerability exclusions also, remove the `check-format` target and move the formatting logic into `go.mk` Signed-off-by: Xavier Coulon <xcoulon@redhat.com>
09d19e0 to
6267eab
Compare
|
Note GitHub couldn't provide a complete incremental comparison for this pull request, so CodeRabbit is performing a full review instead. This review may take a little longer. |
coderabbitai
Bot
removed
documentation
There was a problem hiding this comment.
Actionable comments posted: 1
♻️ Duplicate comments (2)
go.mod (1)
3-5: 🗄️ Data Integrity & Integration | 🟠 Major | 🏗️ Heavy liftAlign downstream Go module contracts before merging.
Line 3 now requires Go 1.26.0, and Line 5 selects
go1.26.5. The linkedtoolchain-common,host-operator, andtoolchain-e2emodules still declare Go 1.24.4 andgo1.24.13while directly depending on this module. Their CI therefore remains on an older declared baseline.Update the downstream modules and their documentation, or explicitly test and document the required
GOTOOLCHAINswitching behavior. Otherwise, downstream builds can fail during module resolution.Verify the declarations and workflow settings with:
#!/usr/bin/env bash set -euo pipefail for repo in ../toolchain-common ../host-operator ../toolchain-e2e; do if [ -f "$repo/go.mod" ]; then printf '%s\n' "--- $repo/go.mod ---" rg -n -C 2 '^(go|toolchain) |github.com/codeready-toolchain/api' "$repo/go.mod" || true rg -n -A 5 -B 3 'go-version-file: go.mod|setup-go|GOTOOLCHAIN' \ "$repo/.github/workflows" 2>/dev/null || true fi done🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@go.mod` around lines 3 - 5, Align the Go version and toolchain declarations in the downstream modules toolchain-common, host-operator, and toolchain-e2e with this module’s go.mod, including their documentation and CI workflow settings. Alternatively, explicitly configure, test, and document the required GOTOOLCHAIN switching behavior so direct dependency resolution remains reliable.Source: Linked repositories
make/generate.mk (1)
39-51: 🎯 Functional Correctness | 🟠 Major | ⚡ Quick winDefine and pin
CRD_REF_DOCSbefore merging.The changed tool block still does not define
CRD_REF_DOCS. The target at Line 50 and the command at Line 51 therefore expand to empty values, sogen-crd-ref-docscannot install or execute the generator.Line 51 also uses
@latest. This makes generated API documentation depend on an unreviewed upstream release. DefineCRD_REF_DOCSunderLOCALBINand install a reviewed fixed version. Either removeCONTROLLER_TOOLS_VERSIONat Line 42 or use it in the controller-gen installation.Verify the expansion with:
#!/usr/bin/env bash set -euo pipefail rg -n -C 2 \ 'CRD_REF_DOCS|crd-ref-docs|CONTROLLER_TOOLS_VERSION|go install' \ Makefile make go.mod go.sum 2>/dev/null || true make -n gen-crd-ref-docs 2>&1 | sed -n '1,80p' || true🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@make/generate.mk` around lines 39 - 51, Define CRD_REF_DOCS under LOCALBIN before its target, and pin the crd-ref-docs installation to a reviewed fixed version instead of `@latest` so gen-crd-ref-docs expands and installs deterministically. In the controller-gen target, either remove the unused CONTROLLER_TOOLS_VERSION or apply it to the installed controller-tools version, then verify make -n gen-crd-ref-docs produces non-empty paths and a pinned install command.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@make/generate.mk`:
- Around line 53-56: Remove the duplicate manifests target definition, retaining
a single .PHONY declaration and recipe for manifests with its existing
CONTROLLER_GEN command.
---
Duplicate comments:
In `@go.mod`:
- Around line 3-5: Align the Go version and toolchain declarations in the
downstream modules toolchain-common, host-operator, and toolchain-e2e with this
module’s go.mod, including their documentation and CI workflow settings.
Alternatively, explicitly configure, test, and document the required GOTOOLCHAIN
switching behavior so direct dependency resolution remains reliable.
In `@make/generate.mk`:
- Around line 39-51: Define CRD_REF_DOCS under LOCALBIN before its target, and
pin the crd-ref-docs installation to a reviewed fixed version instead of `@latest`
so gen-crd-ref-docs expands and installs deterministically. In the
controller-gen target, either remove the unused CONTROLLER_TOOLS_VERSION or
apply it to the installed controller-tools version, then verify make -n
gen-crd-ref-docs produces non-empty paths and a pinned install command.
🪄 Autofix
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Enterprise
Run ID: a8322b52-0886-4bb0-b02b-5c5bc7e285a6
⛔ Files ignored due to path filters (1)
go.sumis excluded by!**/*.sum
📒 Files selected for processing (8)
.github/workflows/ci-build.yml.github/workflows/verify-dependencies.yml.govulncheck.yamlgo.modmake/format.mkmake/generate.mkmake/go.mkmake/gofmt_exclude
🔗 Linked repositories identified
CodeRabbit considers these linked repositories for cross-repo context during reviews:
codeready-toolchain/api(manual)codeready-toolchain/toolchain-common(manual) → reviewed against open PR#543upgrade-go-1.26-commoninstead of the default branchcodeready-toolchain/host-operator(manual) → reviewed against open PR#1290upgrade-go-1.26-hostinstead of the default branchcodeready-toolchain/toolchain-e2e(manual) → reviewed against open PR#1313upgrade-go-1.26-e2einstead of the default branch
💤 Files with no reviewable changes (1)
- make/format.mk
🚧 Files skipped from review as they are similar to previous changes (3)
- make/gofmt_exclude
- .github/workflows/verify-dependencies.yml
- make/go.mk
📜 Review details
⏰ Context from checks skipped due to timeout. (1)
- GitHub Check: Verify Dependencies
🧰 Additional context used
📓 Path-based instructions (1)
**
⚙️ CodeRabbit configuration file
-Focus on major issues impacting performance, readability, maintainability and security. Avoid nitpicks and avoid verbosity.
Files:
go.modmake/generate.mk
🪛 zizmor (1.29.0)
.github/workflows/ci-build.yml
[error] 21-21: runtime artifacts potentially vulnerable to a cache poisoning attack (cache-poisoning): enables caching by default
(cache-poisoning)
🔀 Multi-repo context codeready-toolchain/toolchain-common, codeready-toolchain/host-operator, codeready-toolchain/toolchain-e2e
Linked repositories findings
codeready-toolchain/toolchain-common
Inspected the branch of open PR #543. It directly depends on github.com/codeready-toolchain/api and declares Go 1.24.4/toolchain 1.24.13. [::codeready-toolchain/toolchain-common::]
codeready-toolchain/host-operator
Inspected the branch of open PR #1290. It directly depends on the API module and remains on Go 1.24.4/toolchain 1.24.13. [::codeready-toolchain/host-operator::]
codeready-toolchain/toolchain-e2e
Inspected the branch of open PR #1313. It directly depends on the API module, declares Go 1.24.4/toolchain 1.24.13, and documents Go 1.24.x tooling requirements. [::codeready-toolchain/toolchain-e2e::]
These repositories show downstream Go-version differences, but no observed consumers of the removed generation or formatting targets.
🔇 Additional comments (4)
go.mod (1)
40-46: LGTM!make/generate.mk (1)
32-35: LGTM!.github/workflows/ci-build.yml (1)
21-21: 🔒 Security & PrivacyNo cache-isolation change is required.
pull_requestcaches are scoped to the pull-request merge ref and cannot be restored by latermasterruns. This workflow has no privileged trigger or shared cache scope that creates the described poisoning path.> Likely an incorrect or invalid review comment..govulncheck.yaml (1)
1-1: LGTM!
| .PHONY: manifests | ||
| manifests: $(CONTROLLER_GEN) ## Generate WebhookConfiguration, ClusterRole and CustomResourceDefinition objects. | ||
| $(CONTROLLER_GEN) rbac:roleName=manager-role crd webhook paths="./api/..." output:crd:artifacts:config=config/crd/bases | ||
|
|
There was a problem hiding this comment.
📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -eu
printf '%s\n' '--- make/generate.mk ---'
cat -n make/generate.mk | sed -n '1,80p'
printf '%s\n' '--- manifests definitions ---'
rg -n -C 3 '^[[:space:]]*manifests([[:space:]]*:|[[:space:]]*::=)' make/generate.mk Makefile make 2>/dev/null || true
printf '%s\n' '--- standalone duplicate-target check ---'
python3 - <<'PY'
from pathlib import Path
import re
path = Path("make/generate.mk")
targets = {}
for number, line in enumerate(path.read_text().splitlines(), 1):
match = re.match(r"^([A-Za-z0-9_.-]+)\s*:", line)
if match:
targets.setdefault(match.group(1), []).append(number)
print({target: lines for target, lines in targets.items() if len(lines) > 1})
PYRepository: codeready-toolchain/api
Length of output: 6356
Remove the duplicate manifests target.
manifests is defined twice with the same recipe. GNU Make warns about the overridden recipe and uses the later definition. Keep one definition to prevent future divergence.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@make/generate.mk` around lines 53 - 56, Remove the duplicate manifests target
definition, retaining a single .PHONY declaration and recipe for manifests with
its existing CONTROLLER_GEN command.
Signed-off-by: Xavier Coulon <xcoulon@redhat.com>
0669bfd to
20ed932
Compare
Signed-off-by: Xavier Coulon <xcoulon@redhat.com>
|
3 participants
also, removed outdated vulnerability exclusions
also, remove the
check-formattarget and move the formatting logic intogo.mkNote: based on #519, but can be isolated if needed
See also:
Signed-off-by: Xavier Coulon xcoulon@redhat.com
Summary by CodeRabbit