Bump golang from 1.24 to 1.26#406
Conversation
Bumps golang from 1.24 to 1.26. --- updated-dependencies: - dependency-name: golang dependency-version: '1.26' dependency-type: direct:production update-type: version-update:semver-minor ... Signed-off-by: dependabot[bot] <support@github.com>
dependabot
Bot
added
dependencies
dependabot
Bot
added
dependencies
WalkthroughThe Go base image version is upgraded from Changes
Estimated code review effort🎯 1 (Trivial) | ⏱️ ~2 minutes 🚥 Pre-merge checks | ✅ 11 | ❌ 1❌ Failed checks (1 inconclusive)
✅ Passed checks (11 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Review rate limit: 9/10 reviews remaining, refill in 6 minutes. Comment |
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: dependabot[bot] The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
|
Hi @dependabot[bot]. Thanks for your PR. I'm waiting for a openshift member to verify that this patch is reasonable to test. If it is, they should reply with Regular contributors should join the org to skip this step. Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
openshift-ci
Bot
added
the
needs-ok-to-test
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (2)
Dockerfile (1)
8-8: ⚡ Quick winAvoid
alpine:latestfor reproducible, safer builds.Using
FROM alpine:latestmeans your runtime base can change underneath you between builds (including security updates/vulnerability fixes and potential incompatibilities). Pinning to a specific Alpine version (and ideally a digest) improves reproducibility and supply-chain control.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@Dockerfile` at line 8, The Dockerfile uses an unpinned base image ("FROM alpine:latest"), which leads to non-reproducible builds; update the FROM instruction to pin a specific Alpine version (e.g., "alpine:3.18" or better, an image digest) so the base image remains stable and predictable across builds; change the FROM line accordingly and include the chosen version/digest in the Dockerfile.Dockerfile.arm64 (1)
12-12: ⚡ Quick winAvoid
arm64v8/alpine:latestfor reproducible, safer builds.
FROM arm64v8/alpine:latestcan drift over time. Consider pinning to a specific Alpine release (and ideally digest) for reproducibility and vulnerability management parity with amd64.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@Dockerfile.arm64` at line 12, Replace the floating base image reference in the Dockerfile FROM instruction (currently "FROM arm64v8/alpine:latest") with a specific Alpine release tag (e.g., "alpine:3.18.2" or equivalent arm64 variant) and preferably pin to an immutable digest (sha256) to ensure reproducible, secure builds; update the FROM line to use the chosen version/digest and document the chosen tag/digest in the commit message so future reviewers know why it was pinned.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@Dockerfile`:
- Line 1: Dockerfile is using golang:1.26 while go.mod pins toolchain go1.24.6
causing Go to download the older toolchain during build; fix by either updating
go.mod's "go" and "toolchain" directives to match 1.26 (e.g., change toolchain
to go1.26.x in go.mod) or ensure the build uses the container's toolchain by
exporting GOTOOLCHAIN=local before invoking the build (set GOTOOLCHAIN=local in
hack/build-go.sh or export it in the Dockerfile prior to RUN ./hack/build-go.sh)
so plain go build uses the local Go image instead of downloading toolchains.
In `@Dockerfile.arm64`:
- Line 1: Update the base image in the Dockerfile FROM line to match the go
toolchain in go.mod: replace the current "golang:1.26" base image with
"golang:1.24.6" so the Docker build uses the same Go version as the toolchain
directive and avoids Go downloading/selecting a different toolchain at build
time.
---
Nitpick comments:
In `@Dockerfile`:
- Line 8: The Dockerfile uses an unpinned base image ("FROM alpine:latest"),
which leads to non-reproducible builds; update the FROM instruction to pin a
specific Alpine version (e.g., "alpine:3.18" or better, an image digest) so the
base image remains stable and predictable across builds; change the FROM line
accordingly and include the chosen version/digest in the Dockerfile.
In `@Dockerfile.arm64`:
- Line 12: Replace the floating base image reference in the Dockerfile FROM
instruction (currently "FROM arm64v8/alpine:latest") with a specific Alpine
release tag (e.g., "alpine:3.18.2" or equivalent arm64 variant) and preferably
pin to an immutable digest (sha256) to ensure reproducible, secure builds;
update the FROM line to use the chosen version/digest and document the chosen
tag/digest in the commit message so future reviewers know why it was pinned.
🪄 Autofix (Beta)
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: Repository: openshift/coderabbit/.coderabbit.yaml
Review profile: CHILL
Plan: Enterprise
Run ID: 668626c2-3257-4d6d-8df6-fbb71f5f8d63
📒 Files selected for processing (2)
DockerfileDockerfile.arm64
| @@ -1,4 +1,4 @@ | |||
| FROM golang:1.24 | |||
| FROM golang:1.26 | |||
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "go.mod (toolchain + go directives):"
sed -n '1,40p' go.mod
echo
echo "hack/build-go.sh: look for go invocations and any GOTOOLCHAIN pinning:"
if [ -f hack/build-go.sh ]; then
rg -n --context 3 'GOTOOLCHAIN|toolchain|go1\.' hack/build-go.sh || true
rg -n --context 2 '\bgo (build|test|list|install)\b' hack/build-go.sh || true
else
echo "Missing hack/build-go.sh in repo root; adjust path if different."
fiRepository: openshift/whereabouts-cni
Length of output: 1546
🏁 Script executed:
# Check if hack/build-go.sh exists and read it
fd -t f 'build.*\.sh' . 2>/dev/null | head -20Repository: openshift/whereabouts-cni
Length of output: 170
🏁 Script executed:
# Read the Dockerfile to understand the full context
cat -n DockerfileRepository: openshift/whereabouts-cni
Length of output: 871
🏁 Script executed:
# Check for any .sh files in hack directory
ls -la hack/ 2>/dev/null || echo "No hack directory found"Repository: openshift/whereabouts-cni
Length of output: 994
🏁 Script executed:
cat -n hack/build-go.shRepository: openshift/whereabouts-cni
Length of output: 2602
Go toolchain mismatch: golang:1.26 builder with toolchain go1.24.6 in go.mod.
The Dockerfile uses golang:1.26, but go.mod pins toolchain go1.24.6. Since hack/build-go.sh does not set GOTOOLCHAIN=local and invokes plain go build, Go 1.26 will attempt to download and use the pinned Go 1.24.6 toolchain per the go.mod directive. This adds unnecessary network dependency and slows the Docker build.
Recommended fixes:
- Update
go.modtogo 1.26andtoolchain go1.26.x, or - Add
GOTOOLCHAIN=localto the build environment inhack/build-go.sh(or in the Dockerfile beforeRUN ./hack/build-go.sh)
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@Dockerfile` at line 1, Dockerfile is using golang:1.26 while go.mod pins
toolchain go1.24.6 causing Go to download the older toolchain during build; fix
by either updating go.mod's "go" and "toolchain" directives to match 1.26 (e.g.,
change toolchain to go1.26.x in go.mod) or ensure the build uses the container's
toolchain by exporting GOTOOLCHAIN=local before invoking the build (set
GOTOOLCHAIN=local in hack/build-go.sh or export it in the Dockerfile prior to
RUN ./hack/build-go.sh) so plain go build uses the local Go image instead of
downloading toolchains.
| @@ -1,4 +1,4 @@ | |||
| FROM golang:1.24 | |||
| FROM golang:1.26 | |||
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
# Find and read go.mod to verify toolchain version
find . -name "go.mod" -type f | head -5Repository: openshift/whereabouts-cni
Length of output: 78
🏁 Script executed:
# Find and read hack/build-go.sh to understand toolchain handling
find . -path "*/hack/build-go.sh" -type fRepository: openshift/whereabouts-cni
Length of output: 88
🏁 Script executed:
cat -n ./go.mod | head -20Repository: openshift/whereabouts-cni
Length of output: 801
🏁 Script executed:
cat -n ./hack/build-go.shRepository: openshift/whereabouts-cni
Length of output: 2602
Use golang:1.24.6 in Dockerfile.arm64 to match the go.mod toolchain directive.
The FROM golang:1.26 creates a mismatch with go.mod's toolchain go1.24.6 directive. When hack/build-go.sh runs go build, Go 1.26 will detect the toolchain directive and attempt to download/select Go 1.24.6 instead, adding unnecessary overhead to the build process. Pin the base image to golang:1.24.6 to match the intended toolchain.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@Dockerfile.arm64` at line 1, Update the base image in the Dockerfile FROM
line to match the go toolchain in go.mod: replace the current "golang:1.26" base
image with "golang:1.24.6" so the Docker build uses the same Go version as the
toolchain directive and avoids Go downloading/selecting a different toolchain at
build time.
Bumps golang from 1.24 to 1.26.
Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting
@dependabot rebase.Dependabot commands and options
You can trigger Dependabot actions by commenting on this PR:
@dependabot rebasewill rebase this PR@dependabot recreatewill recreate this PR, overwriting any edits that have been made to it@dependabot show <dependency name> ignore conditionswill show all of the ignore conditions of the specified dependency@dependabot ignore this major versionwill close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this minor versionwill close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this dependencywill close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)Summary by CodeRabbit