Add Helm 3 CLI download links alongside Helm 4

[sowmya-sl]

Helm 3 remains available for existing workflows. This adds a separate ConsoleCLIDownload resource so both versions appear on the CLI downloads page.

Reviewers and assignees:

Summary by CodeRabbit

Summary by CodeRabbit

• New Features
  • Added Helm 3 CLI download information, including updated metadata and a link to the latest Helm 3 client bundle.
• Bug Fixes
  • Updated the existing Helm 4 CLI download link to point to the newer Helm 4 client bundle (v4.2.3).

[openshift-ci]

Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Repository YAML (base), Central YAML (inherited)

Review profile: CHILL

Plan: Enterprise

Run ID: 5838081f-3368-48b9-9feb-ae9b3bbe5893

📥 Commits

Reviewing files that changed from the base of the PR and between b16ee7e and ef7523b.

📒 Files selected for processing (1)

• manifests/07-downloads-helm.yaml

🔗 Linked repositories identified

CodeRabbit considers these linked repositories for cross-repo context during reviews:

• openshift/console (manual)

🚧 Files skipped from review as they are similar to previous changes (1)

• manifests/07-downloads-helm.yaml

📜 Recent review details

🧰 Additional context used

🔀 Multi-repo context

No additional cross-repository context was found beyond the prior findings. The change is confined to a manifest and is compatible with the existing ConsoleCLIDownload rendering and HTTPS URL contract.

---

Walkthrough

Updates the Helm 4 CLI bundle URL and adds a ConsoleCLIDownload resource for Helm 3 with Helm-specific metadata and a latest client bundle link.

Changes

Helm CLI download resources

Layer / File(s)	Summary
Helm CLI download resources manifests/07-downloads-helm.yaml	Updates the Helm 4 link to version 4.2.3 and adds the helm3-download-links resource with Helm 3 metadata and the latest client bundle URL.

Estimated code review effort: 1 (Trivial) | ~2 minutes

Suggested reviewers: jhadvig, therealjon

🚥 Pre-merge checks | ✅ 13 | ❌ 2

❌ Failed checks (2 warnings)

Check name	Status	Explanation	Resolution
Title check	⚠️ Warning	The title matches the change, but it is missing the required Jira issue prefix from the repository template.	Prefix the title with the Jira key, e.g. "CONSOLE-XXXX: Add Helm 3 CLI download links alongside Helm 4".
Description check	⚠️ Warning	The description is missing most required template sections, including analysis, solution, test setup, test cases, browser conformance, and additional info.	Add the missing template sections and fill in analysis/root cause, solution, test setup, test cases, browser conformance, and additional info.

✅ Passed checks (13 passed)

Check name	Status	Explanation
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Stable And Deterministic Test Names	✅ Passed	PR only changes a Helm manifest; no Ginkgo test titles or test files are modified.
Test Structure And Quality	✅ Passed	Only manifests/07-downloads-helm.yaml changed; no Ginkgo test code or test patterns were modified.
Microshift Test Compatibility	✅ Passed	Only a Helm manifest changed; no new Ginkgo tests or MicroShift-sensitive APIs/features were added.
Single Node Openshift (Sno) Test Compatibility	✅ Passed	PASS: PR only updates a manifest; no new Ginkgo/e2e tests or SNO-sensitive assumptions were added.
Topology-Aware Scheduling Compatibility	✅ Passed	Only ConsoleCLIDownload manifests changed; no pod specs, replicas, affinity, selectors, tolerations, or topology-aware scheduling fields were added.
Ote Binary Stdout Contract	✅ Passed	Only manifests/07-downloads-helm.yaml changed; no process-level code (main/TestMain/etc.) was touched, so stdout contract risk is absent.
Ipv6 And Disconnected Network Test Compatibility	✅ Passed	Only a YAML manifest changed; no new Ginkgo/e2e tests or network-sensitive test code was added.
No-Weak-Crypto	✅ Passed	Touched manifest contains no MD5/SHA1/DES/RC4/3DES/Blowfish/ECB or secret comparisons; changes are just Helm download links/text.
Container-Privileges	✅ Passed	The changed file is only a ConsoleCLIDownload manifest; it contains no privileged, host*, SYS_ADMIN, root, or allowPrivilegeEscalation settings.
No-Sensitive-Data-In-Logs	✅ Passed	The only changed file is a ConsoleCLIDownload manifest; no log statements or sensitive fields (passwords/tokens/PII) appear.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

_{Comment @coderabbitai help to get the list of available commands.}

[webbnh]

This looks OK to me, but I've got a suggestion, a question, and a proposed revision (I'll let you guess which is which 😉).

/lgtm

[webbnh]

Consider updating this to 4.2.3.

(Presumably, this would be better done in a separate PR, but the additional hassle doesn't seem worthwhile, given the narrow scope and low complexity of this PR.)

[webbnh]

Just out of curiosity, why does the first sentence use verbiage different from the Helm 4 text?

Regardless, given that we're including that second sentence, we might want to go all-in and say something like "Helm 3 continues to be provided for operational continuity, but it will not be compatible with future releases of OCP and so customers are encouraged to upgrade to Helm 4." (I suggest conferring with Marina and Jocelyn on detailed content and wording.)

[mkumku]

So, we are concerned that having it on the console will imply support, we simply should redirect to the compatibility matrix then: https://access.redhat.com/articles/7145580 .
I would say, under both sections:
For Helm CLI compatibility with OpenShift releases refer to article https://access.redhat.com/articles/7145580.

[webbnh]

we are concerned that having it on the console will imply support

@mkumku, we expect that this documentation is version-specific -- e.g., the change proposed here is specifically for OCP 5.0. We will backport this change to OCP 4.22, and presumably it will propagate automatically to OCP 4.23. For OCP 5.2 (and, perhaps for 5.1), we will remove the Helm v3 section.

So, while I have no objection to adding a reference to a support statement, I don't think it's necessary; and, I don't think it's really useful to make a statement about compatibility -- what we are advertising here is supposed to be compatible with the platform where it is being advertised!

[webbnh]

I don't know how these changes relate to the content served from https://console.redhat.com/openshift/downloads -- that content seems to be version independent, which poses exactly the compatibility challenges that you are raising. If that content comes from here, then, yeah, we definitely need pointers from here to both compatibility and support documentation. 😛

[sowmya-sl]

So do I add a link to compatibility matrix or not? 😕

[sowmya-sl]

@mkumku @webbnh ?

[mkumku]

Hi Sowmya, since this is the OCP cluster, where you know the version of the cluster and you can adjust the version of Helm you are pointing to, then probably you can skip the link to the support matrix.

My only question to you, since we cannot use latest for Helm v4, do you plan updating this link with each z-stream release of Helm?
Maybe we can simply point to this directory: https://mirror.openshift.com/pub/cgw/helm/ . This directory will contain all the available Helm v4 binaries. And then this will remove the need of submitting a new PR with each z-release. And then it will make sense to share the compatibility matrix page.
I will leave this between you and @webbnh to decide what makes more sense from development workflow. Both options work for me.

[openshift-ci]

@sowmya-sl: all tests passed!

Full PR test history. Your PR dashboard.

Details

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 kubernetes-sigs/prow repository. I understand the commands that are listed here.

[webbnh]

This looks good for now. Let's merge it as is and then open another PR to work on the Helm v4 download link: we should make it point to the directory which contains all the versions, and we should change the link text to something like "Helm v4 Downloads Directory".

/lgtm

[openshift-ci]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: sowmya-sl, webbnh
Once this PR has been reviewed and has the lgtm label, please assign spadgett for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[webbnh]

/verified by CI

[openshift-ci-robot]

@webbnh: This PR has been marked as verified by CI.

Details

In response to this:

/verified by CI

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.

[webbnh]

@sowmya-sl (or @spadgett or anyone else with write access to the repo...), I believe that the Jira for this PR is OSDOCS-20110. If you could fix the title and ask the bot to confirm it, we can move this PR closer to merging....