NO-ISSUE: Update registry.access.redhat.com/ubi9/go-toolset Docker tag to v1.26#2139
NO-ISSUE: Update registry.access.redhat.com/ubi9/go-toolset Docker tag to v1.26#2139red-hat-konflux[bot] wants to merge 1 commit into
Conversation
…g to v1.26 Signed-off-by: red-hat-konflux <126015336+red-hat-konflux[bot]@users.noreply.github.com>
|
@red-hat-konflux[bot]: This pull request explicitly references no jira issue. DetailsIn response to this:
Instructions 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 openshift-eng/jira-lifecycle-plugin repository. |
WalkthroughThis PR updates the Go toolset base image version from 1.25 to 1.26 across seven Dockerfiles used for building assisted-installer and related controller components. All changes are identical single-line updates to the builder stage base image tag, with no other build logic, runtime behavior, or configuration affected. ChangesGo Toolset Upgrade
🎯 1 (Trivial) | ⏱️ ~3 minutes 🚥 Pre-merge checks | ✅ 11 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (11 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Comment |
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 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 `@Dockerfile.assisted-installer`:
- Line 1: The FROM line uses an invalid Red Hat tag "1.26"; update the image
reference in the Dockerfile's FROM instruction
(registry.access.redhat.com/ubi9/go-toolset:1.26) to a valid Red Hat tag or omit
the tag to use the default (e.g., use registry.access.redhat.com/ubi9/go-toolset
or a documented v9.x-<timestamp> tag such as v9.6-1756993846) so the base image
can be pulled successfully during build.
🪄 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: fce15ac4-d802-447f-906a-04d8b1a92920
📒 Files selected for processing (7)
Dockerfile.assisted-installerDockerfile.assisted-installer-buildDockerfile.assisted-installer-controllerDockerfile.assisted-installer-controller-downstreamDockerfile.assisted-installer-controller-mceDockerfile.assisted-installer-downstreamDockerfile.assisted-installer-mce
| @@ -1,4 +1,4 @@ | |||
| FROM registry.access.redhat.com/ubi9/go-toolset:1.25 AS builder | |||
| FROM registry.access.redhat.com/ubi9/go-toolset:1.26 AS builder | |||
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Description: Verify the go-toolset:1.26 image exists in Red Hat registry
# Check if the image can be pulled (read-only check)
echo "Checking if go-toolset:1.26 is available..."
docker manifest inspect registry.access.redhat.com/ubi9/go-toolset:1.26 > /dev/null 2>&1
if [ $? -eq 0 ]; then
echo "✓ Image registry.access.redhat.com/ubi9/go-toolset:1.26 is available"
# Get image details
docker manifest inspect registry.access.redhat.com/ubi9/go-toolset:1.26 | jq -r '.manifests[0].platform | "Platform: \(.os)/\(.architecture)"'
else
echo "✗ Image registry.access.redhat.com/ubi9/go-toolset:1.26 not found or not accessible"
fiRepository: openshift/assisted-installer
Length of output: 200
🌐 Web query:
Go 1.26 release notes breaking changes migration guide
💡 Result:
There’s no dedicated “breaking changes / migration guide” section titled that way for Go 1.26. Instead, the official Go 1.26 release notes document all language, toolchain, and library changes (and any potential migration-impacting items) in one place, while also emphasizing Go’s compatibility promise (i.e., most programs should continue to compile and run as before) [1]. Key migration-impacting items you should review in the Go 1.26 notes: 1) go.mod init behavior change (affects module “go” version and compatibility checks) - New go.mod files created by go mod init use a lower go version: for Go 1.26 and its minor releases it creates go 1.25.0; and for Go 1.26 release candidates it creates go 1.24.0 [1]. 2) go fix revamped (automation for codebase modernization) - The release notes describe a “completely revamped” go fix command, using Go’s analysis framework and including “modernizers” plus a source-level inliner via //go:fix inline directives [1]. - Practically, this is the official mechanism intended to help upgrade code to newer idioms and APIs with safe (behavior-preserving) fixes, where applicable [1]. 3) Tooling / commands deleted (can break scripts or documentation tooling) - The release notes state that cmd/doc and go tool doc have been deleted [1]. - If you rely on those commands in CI or developer workflows, you’ll need to migrate to the replacement described in the notes (the release notes indicate go doc as the replacement, by taking the flags/arguments with the same behavior) [1]. 4) New syntax/type-system features that may affect code generation or constraints - The blog release post calls out two significant language/type refinements: new can take an expression (not only a type) and generic types may refer to themselves in their own type parameter list [2]. These can affect code patterns and any tooling that parses/rewrites Go source across versions [2]. If you want, tell me what you mean by “breaking changes” for your situation (build failures, API/library changes, tool invocation changes, or go.mod/go version policy), and I’ll extract the most relevant migration steps from the official Go 1.26 notes and map them to a checklist for upgrading. Sources: [1] https://go.dev/doc/go1.26 [2] https://go.dev/blog/go1.26
Citations:
🏁 Script executed:
#!/bin/bash
# Check if the previous version (1.25) exists
echo "Checking if go-toolset:1.25 is available..."
docker manifest inspect registry.access.redhat.com/ubi9/go-toolset:1.25 > /dev/null 2>&1
if [ $? -eq 0 ]; then
echo "✓ Image go-toolset:1.25 is available"
else
echo "✗ Image go-toolset:1.25 is NOT available"
fi
# Try to find available versions by checking common version tags
echo ""
echo "Checking other potential go-toolset versions in ubi9..."
for version in 1.24 1.27 1.23 1.22; do
docker manifest inspect registry.access.redhat.com/ubi9/go-toolset:$version > /dev/null 2>&1
if [ $? -eq 0 ]; then
echo "✓ go-toolset:$version is available"
fi
doneRepository: openshift/assisted-installer
Length of output: 214
🏁 Script executed:
#!/bin/bash
# Read the actual Dockerfile to verify the change
echo "Reading Dockerfile.assisted-installer..."
if [ -f "Dockerfile.assisted-installer" ]; then
head -5 Dockerfile.assisted-installer
else
echo "File not found. Searching for Dockerfile..."
find . -name "Dockerfile.assisted-installer" -type f
fiRepository: openshift/assisted-installer
Length of output: 274
🏁 Script executed:
#!/bin/bash
# Check git history for this file
echo "Checking git history for Dockerfile.assisted-installer..."
git log --oneline -n 10 Dockerfile.assisted-installer 2>/dev/null || echo "Git log not available"
echo ""
echo "Checking recent changes to the file..."
git show HEAD:Dockerfile.assisted-installer 2>/dev/null | head -1 || echo "Git show not available"
echo ""
echo "Checking if file was recently modified..."
git diff HEAD~1 Dockerfile.assisted-installer 2>/dev/null | head -20 || echo "Git diff not available"Repository: openshift/assisted-installer
Length of output: 366
🌐 Web query:
Red Hat UBI9 go-toolset available versions registry.access.redhat.com
💡 Result:
Red Hat UBI9 go-toolset is pulled from: registry.access.redhat.com/ubi9/go-toolset [1]. About “available versions”: - Red Hat’s documentation for the UBI9 go-toolset container image shows using the image name registry.access.redhat.com/ubi9/go-toolset (and implies the image can be pulled without an explicit version tag, e.g., the default/latest tag) [1]. - Red Hat’s published guidance also describes that the container image contents correspond to specific Go Toolset module/package versions for given RHEL major versions (for example, in one Go Toolset doc page, the RHEL 9 Go Toolset package is shown as go-toolset-1.17.7) [2]. A concrete “tag/version” example for the UBI9 image (docker tag): - The docker tag format used in automation/refs is like v9.x-<unix_timestamp>, and there are recent tag examples for registry.access.redhat.com/ubi9/go-toolset such as v9.7-1776962329 and v9.6-1749636489 [3][4]. If you specifically need the complete list of tags for registry.access.redhat.com/ubi9/go-toolset as of today (2026-05-20), I did not find an official Red Hat page that enumerates every tag under that repository; Red Hat’s docs focus on how to pull the image rather than listing all tag values [1][2]. In practice, you would query the registry API or use tooling (e.g., skopeo/podman against the registry) to enumerate tags, but I didn’t retrieve an authoritative registry tag listing from sources above.
Citations:
- 1: https://docs.redhat.com/en/documentation/red_hat_developer_tools/1/html-single/using_go_1.22_toolset/index
- 2: https://docs.redhat.com/en/documentation/red_hat_developer_tools/1/html/using_go_1.17.7_toolset/assembly_container-images-with-go-toolset
- 3: quay/release-readiness@b174f17
- 4: redhat-developer/rhdh-operator@5e248c7
🌐 Web query:
Red Hat UBI9 go-toolset tag format versions registry.access.redhat.com how to reference
💡 Result:
To reference the Red Hat UBI9 Go Toolset container image from registry.access.redhat.com, use the image name (optionally with a tag): 1) Default “latest” style reference (as shown in Red Hat docs) - registry.access.redhat.com/ubi9/go-toolset Red Hat’s documentation shows pulling this image with: # podman pull registry.access.redhat.com/ubi9/go-toolset [1][2] 2) How to specify/override the tag format - Red Hat’s docs you can access publicly show the repository/image reference without an explicit tag (so you typically rely on the registry’s default tag behavior when you omit the tag). [1][2] - For explicit tags, Red Hat publishes versioned tags; for example, a recent automation update in a public repo referenced a specific tag value: registry.access.redhat.com/ubi9/go-toolset:v9.6-1756993846. [3] So, in practice: - registry.access.redhat.com/ubi9/go-toolset: (where should be one of the version tags published for that repository, e.g., the example v9.6-1756993846). [3] If you want the authoritative list of available tags, you should query the registry tag listing for the specific repository (registry.access.redhat.com/ubi9/go-toolset) and select the exact tag you need, then reference it as above. (The public docs I found show the pull/image reference; the dynamic “available tags” list itself isn’t included in the cited docs.) [1][2]
Citations:
- 1: https://docs.redhat.com/en/documentation/red_hat_developer_tools/1/html-single/using_go_1.22_toolset/index
- 2: https://docs.redhat.com/en/documentation/red_hat_developer_tools/1/html/using_go_1.22_toolset/assembly_container-images-with-go-toolset_using-go-toolset
- 3: redhat-developer/rhdh-operator@e436816
Fix the go-toolset image tag format—"1.26" does not exist in Red Hat's registry.
The tag 1.26 does not match Red Hat's published tag format for UBI9 go-toolset images. Red Hat publishes tags in the format v9.x-<timestamp> (e.g., v9.6-1756993846) or uses the default/latest tag when unspecified. Using :1.26 will cause the build to fail when attempting to pull the image. Update to a valid Red Hat tag or omit the tag to use the default.
🤖 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 `@Dockerfile.assisted-installer` at line 1, The FROM line uses an invalid Red
Hat tag "1.26"; update the image reference in the Dockerfile's FROM instruction
(registry.access.redhat.com/ubi9/go-toolset:1.26) to a valid Red Hat tag or omit
the tag to use the default (e.g., use registry.access.redhat.com/ubi9/go-toolset
or a documented v9.x-<timestamp> tag such as v9.6-1756993846) so the base image
can be pulled successfully during build.
|
[APPROVALNOTIFIER] This PR is APPROVED Approval requirements bypassed by manually added approval. This pull-request has been approved by: red-hat-konflux[bot] The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
|
[APPROVALNOTIFIER] This PR is APPROVED Approval requirements bypassed by manually added approval. This pull-request has been approved by: red-hat-konflux[bot] The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
1 similar comment
|
[APPROVALNOTIFIER] This PR is APPROVED Approval requirements bypassed by manually added approval. This pull-request has been approved by: red-hat-konflux[bot] The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #2139 +/- ##
=======================================
Coverage 48.82% 48.82%
=======================================
Files 20 20
Lines 4397 4397
=======================================
Hits 2147 2147
Misses 2026 2026
Partials 224 224 🚀 New features to boost your workflow:
|
|
@red-hat-konflux[bot]: The following test failed, say
Full PR test history. Your PR dashboard. 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. I understand the commands that are listed here. |
This PR contains the following updates:
1.25→1.26Configuration
📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about this update again.
To execute skipped test pipelines write comment
/ok-to-test.Documentation
Find out how to configure dependency updates in MintMaker documentation or see all available configuration options in Renovate documentation.