ci: update ib-kubernetes version to 093bc63 (of branch network-operator-26.1.x)#2760
ci: update ib-kubernetes version to 093bc63 (of branch network-operator-26.1.x)#2760nvidia-ci-cd wants to merge 1 commit into
Conversation
Signed-off-by: nvidia-ci-cd <svc-cloud-orch-gh@nvidia.com>
Greptile SummaryThis is an automated CI update that bumps the
Confidence Score: 4/5Safe to merge, but the version format change from a semantic tag to a bare 7-character commit hash is worth confirming was intentional and that the corresponding container image was published under that exact tag. All three files receive identical, mechanically consistent version bumps from a named automated workflow. The only notable aspect is that the new version string is a short commit hash rather than a semver tag, unlike every other component in hack/release.yaml — the version format for ib-kubernetes differs from all other components; worth a quick sanity check that the container image exists with this tag. Important Files Changed
Flowchart%%{init: {'theme': 'neutral'}}%%
flowchart TD
A["ib-kubernetes release branch\n(network-operator-26.1.x)"] -->|"GitHub Actions workflow\nrun 28871829458"| B["Commit 093bc63 identified"]
B --> C["Automated PR created\nagainst master"]
C --> D["hack/release.yaml\nversion: 093bc63"]
C --> E["example CR full.yaml\nversion: 093bc63"]
C --> F["example CR full-ocp.yaml\nversion: 093bc63"]
D & E & F --> G["Network Operator build\npulls nvcr.io/nvstaging/mellanox/ib-kubernetes:093bc63"]
%%{init: {'theme': 'base', 'themeVariables': {"darkMode": true, "background": "#0d1117", "primaryColor": "#21262d", "primaryTextColor": "#e6edf3", "primaryBorderColor": "#8b949e", "lineColor": "#8b949e", "textColor": "#e6edf3", "edgeLabelBackground": "#161b22", "actorBkg": "#21262d", "actorBorder": "#8b949e", "actorTextColor": "#e6edf3", "actorLineColor": "#8b949e", "signalColor": "#8b949e", "signalTextColor": "#e6edf3", "noteBkgColor": "#373320", "noteBorderColor": "#d4a72c", "noteTextColor": "#f0e6c0", "labelBoxBkgColor": "#21262d", "labelBoxBorderColor": "#8b949e", "labelTextColor": "#e6edf3", "loopTextColor": "#e6edf3", "activationBkgColor": "#30363d", "activationBorderColor": "#8b949e"}}}%%
flowchart TD
A["ib-kubernetes release branch\n(network-operator-26.1.x)"] -->|"GitHub Actions workflow\nrun 28871829458"| B["Commit 093bc63 identified"]
B --> C["Automated PR created\nagainst master"]
C --> D["hack/release.yaml\nversion: 093bc63"]
C --> E["example CR full.yaml\nversion: 093bc63"]
C --> F["example CR full-ocp.yaml\nversion: 093bc63"]
D & E & F --> G["Network Operator build\npulls nvcr.io/nvstaging/mellanox/ib-kubernetes:093bc63"]
Reviews (1): Last reviewed commit: "ci: update ib-kubernetes version to 093b..." | Re-trigger Greptile |
| repository: nvcr.io/nvstaging/mellanox | ||
| sourceRepository: ib-kubernetes | ||
| version: network-operator-v26.7.0-beta.2 | ||
| version: 093bc63 |
There was a problem hiding this comment.
Bare commit hash used as version
Every other component in this file uses a full semantic version tag (e.g., network-operator-v26.7.0-beta.2), but ib-kubernetes is now pinned to the 7-character short hash 093bc63. Short hashes can be ambiguous in repos with large histories, and this format will be pulled as a container image tag — if the image was not pushed with exactly that tag, the deployment will fail with an image-not-found error at runtime. If this is intentional (e.g., the release pipeline for the network-operator-26.1.x branch hasn't produced a versioned tag yet), it may be worth adding a comment explaining why the version format differs here. Was the container image nvcr.io/nvstaging/mellanox/ib-kubernetes:093bc63 explicitly pushed with this short hash tag, or should this be a full semver tag once the release branch has one?
Automated CI update for component 'ib-kubernetes', created by GitHub actions reusable workflow run 28871829458 for release branch network-operator-26.1.x.