ci: update multus-cni version to 4cbc32b2 (of branch network-operator-26.4.x)

[nvidia-ci-cd]

Automated CI update for component 'multus-cni', created by GitHub actions reusable workflow run 22981297008 for release branch network-operator-26.4.x.

[greptile-apps]

Greptile Summary

This automated CI PR updates the multus-cni version from the named tag network-operator-v26.1.0 to the commit SHA 4cbc32b2 (from the network-operator-26.4.x branch) across all example Custom Resource manifests and the release configuration file.

• All 5 files are updated consistently for the multus-cni component version field.
• The new version is a short (8-character) commit SHA rather than a human-readable release tag, unlike every other component in hack/release.yaml which continues to use network-operator-v26.1.0 — this format inconsistency is worth tracking as the branch moves toward a stable release tag.
• No logic, controller, or operator code is changed; risk is limited to misconfigured image references if the SHA is not yet published to nvcr.io/nvstaging/mellanox.

Confidence Score: 4/5

• This PR is safe to merge with low risk; it is a narrow automated version bump with no logic changes.
• All changes are straightforward version string replacements in example CRs and the release config. The only concern is that the new version is a short commit SHA rather than a named release tag, creating a format inconsistency with other components, but this is a non-blocking style issue for an automated CI PR targeting a pre-release branch.
• hack/release.yaml — worth confirming the short SHA 4cbc32b2 is correctly published to the staging registry before merging.

Important Files Changed

Filename	Overview
hack/release.yaml	Automated update of multus-cni version from network-operator-v26.1.0 to commit SHA 4cbc32b2; only Multus is updated while other components remain on named tags, creating a version format inconsistency.
example/crs/mellanox.com_v1alpha1_nicclusterpolicy_cr-full.yaml	Version field for multus-cni updated from network-operator-v26.1.0 to 4cbc32b2; part of consistent automated bump across all example CRs.
example/crs/mellanox.com_v1alpha1_nicclusterpolicy_cr-ipoib.yaml	Version field for multus-cni updated from network-operator-v26.1.0 to 4cbc32b2; straightforward automated bump.
example/crs/mellanox.com_v1alpha1_nicclusterpolicy_cr-nvidia-ipam.yaml	Version field for multus-cni updated from network-operator-v26.1.0 to 4cbc32b2; straightforward automated bump.
example/crs/mellanox.com_v1alpha1_nicclusterpolicy_cr.yaml	Version field for multus-cni updated from network-operator-v26.1.0 to 4cbc32b2; straightforward automated bump.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[CI Workflow\nnetwork-operator-26.4.x branch] -->|Triggered automated PR| B[PR #2256]
    B --> C[hack/release.yaml\nMultus.version]
    B --> D[cr-full.yaml\nspec.multus.version]
    B --> E[cr-ipoib.yaml\nspec.multus.version]
    B --> F[cr-nvidia-ipam.yaml\nspec.multus.version]
    B --> G[cr.yaml\nspec.multus.version]
    C & D & E & F & G -->|network-operator-v26.1.0 → 4cbc32b2| H[nvcr.io/nvstaging/mellanox/multus-cni:4cbc32b2]

Loading

_{Last reviewed commit: 1cbf457}

[greptile-apps]

Short commit SHA used as version

The multus-cni version is set to a short 8-character commit SHA (4cbc32b2) rather than a tagged release version. All other components in this file (e.g., CniPlugins, Ipoib, nvIpam) use human-readable version tags like network-operator-v26.1.0.

Using a truncated SHA as the version has two concerns:

1. Traceability: It's harder to reason about which release, changelog, or security patch baseline is being deployed without manually looking up the commit.
2. Collision risk: Short SHAs (8 chars) have a small but non-zero probability of ambiguity across a large commit history.

If this is intentional (e.g., the network-operator-26.4.x branch hasn't been tagged yet), consider using the full 40-character SHA for unambiguity, or document why a pre-release SHA is being promoted to master-targeted example configs.