build: upgrade to Go 1.26.5 #521
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,19 +1 @@ | ||
| ignored-vulnerabilities: [] |
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -3,12 +3,6 @@ API_GROUPNAME=toolchain | |
| API_FULL_GROUPNAME=toolchain.dev.openshift.com | ||
| API_VERSION:=v1alpha1 | ||
|
|
||
| ## Tool Binaries | ||
| CONTROLLER_GEN ?= $(LOCALBIN)/controller-gen | ||
| OPENAPI_GEN ?= $(LOCALBIN)/openapi-gen | ||
|
|
@@ -29,6 +23,27 @@ $(CRD_REF_DOCS): go.mod | $(LOCALBIN) ## install crd-ref-docs locally if necessa | |
| 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 | ||
|
|
||
| ## Location to install dependencies to | ||
| LOCALBIN ?= $(shell pwd)/bin | ||
| $(LOCALBIN): | ||
| mkdir -p $(LOCALBIN) | ||
|
|
||
|
|
||
| ## Tool Binaries | ||
| CONTROLLER_GEN ?= $(LOCALBIN)/controller-gen | ||
| OPENAPI_GEN ?= $(LOCALBIN)/openapi-gen | ||
| PATH_TO_CRD_BASES=config/crd/bases | ||
| CONTROLLER_TOOLS_VERSION ?= v0.18.0 | ||
|
|
||
| $(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 | ||
|
Comment on lines
+36
to
+45
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:
💡 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 Citations:
🏁 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): 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
🤖 Prompt for AI Agents |
||
|
|
||
| .PHONY: generate | ||
| generate: generate-object generate-crd gen-crd-ref-docs generate-openapi dispatch-crds ## Generate code containing DeepCopy, DeepCopyInto, and DeepCopyObject method implementations. | ||
|
|
||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🗄️ Data Integrity & Integration | 🟠 Major | 🏗️ Heavy lift
🧩 Analysis chain
🏁 Script executed:
Repository: codeready-toolchain/api
Length of output: 3860
🏁 Script executed:
Repository: codeready-toolchain/toolchain-common
Length of output: 1919
🏁 Script executed:
Repository: codeready-toolchain/host-operator
Length of output: 3435
🏁 Script executed:
Repository: 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:
🏁 Script executed:
Repository: codeready-toolchain/host-operator
Length of output: 3827
🏁 Script executed:
Repository: codeready-toolchain/toolchain-common
Length of output: 2476
🏁 Script executed:
Repository: codeready-toolchain/toolchain-e2e
Length of output: 2390
🏁 Script executed:
Repository: 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):
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 thego-version-fileinput set to ago.modfile, the action performs Go version selection by checking both thetoolchainandgodirectives [1][2][3]. The behavior is as follows: 1. Precedence: If thetoolchaindirective is present in thego.modfile, the action uses the version specified there [1][2][4]. If notoolchaindirective exists, it falls back to the version specified in thegodirective [2][4][5]. 2. Environment Variable Override: The action respects theGOTOOLCHAINenvironment variable [6]. IfGOTOOLCHAINis explicitly set tolocal, the action ignores thetoolchaindirective and defaults to the version defined in thegodirective [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, theversions-manifest.jsonfile, 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 usinggo.modfor version detection, the action's cache keys automatically incorporate the version detected from these directives to prevent cache conflicts [2][3]. If bothgo-versionandgo-version-fileinputs are provided, the explicitgo-versioninput takes precedence and overrides the version detected from thego.modfile [1][2][5].Citations:
🏁 Script executed on all repositories:
Length of output: 2038
Align all Go toolchain contracts with Go 1.26.
Update
README.md,required_tools.adoc, and thego.modfiles fortoolchain-common,host-operator, andtoolchain-e2e. These modules directly require the API module but declare Go 1.24.4 andgo1.24.13; their CI reads those declarations withactions/setup-go. Otherwise, explicitly test and document the requiredGOTOOLCHAINswitching configuration.📍 Affects 2 files
go.mod#L3-L5(this comment)README.md#L10-L10🤖 Prompt for AI Agents
Sources: Path instructions, Linked repositories