[StefanSa]

Summary

• support chart detail and install flows for direct OCI references
• support OCI chart URLs returned by classic repository indexes
• use Radar’s existing Helm registry client and pin the requested chart version
• preserve the existing non-OCI HTTP download path

This extracts the self-contained OCI install gap identified by hisco during review of #1646.

Tests

• focused OCI install and existing OCI helper tests (21 passed)
• go vet ./internal/helm
• gofmt and git diff checks

---

Note

Medium Risk
Changes cluster install and chart-fetch paths and OCI registry auth/timeout behavior; mistakes could break installs or pull wrong chart versions, though HTTP-only flows are preserved and tests are extensive.

Overview
Adds OCI Helm chart support for chart detail, install (with progress), and index entries that point at oci:// URLs.

Centralizes resolution in resolveOCIChartURL (prefix vs full tag/digest refs) and locateChartPath, which wires Helm’s registry client from existing helm registry login credentials and maps OCI latest to an empty version for tag resolution. Chart pulls use newRegistryClientForChartPull (no probe timeout); synchronous registry probes keep the short timeout.

GetChartDetail and install paths branch on OCI repositories; non-OCI installs still use the direct HTTP download path to avoid stale local index cache failures. A chartPathLocator hook supports tests; new oci_install_test.go covers URL resolution, install/detail/progress flows, pre-install rejection, and live registry tag selection.

^{Reviewed by Cursor Bugbot for commit a37624a. Bugbot is set up for automated code reviews on this repo. Configure here.}

[qodo-free-for-open-source-projects]

PR Summary by Qodo

Support OCI chart details and installs

🐞 Bug fix 🧪 Tests 🕐 20-40 Minutes

AI Description

• Supports chart details and installs from direct OCI references and OCI-backed repository indexes.
• Reuses Helm registry credentials while pinning the resolved chart version.
• Preserves direct HTTP downloads for non-OCI charts.

Diagram

graph TD
  A["Chart request"] --> B{"OCI source?"}
  B -->|Yes| C["Helm locator"] --> D["OCI registry"] --> E["Chart archive"] --> F["Chart loader"]
  B -->|No| G["HTTP download"] --> E
  F --> H["Detail or install"]

Loading

High-Level Assessment

The following are alternative approaches to this PR:

1. Use Helm locator for every transport

• ➕ Creates one chart acquisition pipeline.
• ➕ Reduces explicit OCI versus HTTP branching.
• ➖ Reintroduces failures from unrelated stale or missing repository index caches.
• ➖ Changes a proven non-OCI download path beyond the OCI fix scope.

2. Temporarily register OCI sources

• ➕ Could reuse existing OCI source discovery behavior.
• ➕ Centralizes OCI references in the source inventory.
• ➖ Introduces persistent or concurrent configuration side effects.
• ➖ Could mutate source inventory for rejected or failed installations.

Recommendation: Keep the PR's transport-specific approach. Using Helm's locator and existing registry credentials only for OCI enables authenticated pulls and version pinning, while retaining the direct HTTP path that avoids unrelated repository-cache failures and leaving OCI source inventory unchanged.

Files changed (2) +342 / -54

Bug fix (1) +149 / -54

client.goAdd OCI-aware chart resolution to detail and install flows +149/-54

Add OCI-aware chart resolution to detail and install flows

• Adds centralized OCI reference normalization and version-pinned chart location using Helm's registry client. Chart detail and both installation paths now accept direct OCI references and OCI URLs from repository indexes, while non-OCI progress installs retain direct HTTP downloads. Shared chart-detail extraction removes duplicated metadata processing.

internal/helm/client.go

Tests (1) +193 / -0

oci_install_test.goCover direct and indexed OCI chart workflows +193/-0

Cover direct and indexed OCI chart workflows

• Adds focused tests for OCI chart details, standard and progress installations, exact locator arguments, and wrapped registry errors. Tests also verify rejected installs do not perform chart lookup or mutate configured OCI sources.

internal/helm/oci_install_test.go

[cursor]

Cursor Bugbot has reviewed your changes using default effort and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

Want higher recall? High effort reviews run extra passes and find more bugs. A team admin can switch effort levels in the Cursor dashboard.

^{Reviewed by Cursor Bugbot for commit 3309c48. Configure here.}

[qodo-free-for-open-source-projects]

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (1) 📎 Requirement gaps (0) 🎨 UX issues (0) 🔗 Cross-repo conflicts (0) 📜 Skill insights (0)

1. Slow registry downloads fail ✓ Resolved 🐞 Bug ☼ Reliability

Description

locateChartPath uses newRegistryClientConcrete, whose HTTP client has the five-second
ociProbeTimeout intended for registry tag discovery. OCI installs and chart-detail loads now use
that client for archive pulls, so a request taking more than five seconds through a slow registry or
network fails before the chart can load.

Code

internal/helm/client.go[2942]

+		registryClient, err := c.newRegistryClientConcrete()

Evidence

The new locator constructs the registry client at the changed call site and installs it on Helm's
chart locator. That constructor configures an http.Client with ociProbeTimeout, while the
constant and comments explicitly describe five seconds as a bound for synchronous tag lookup rather
than chart downloads; all newly supported OCI detail and install flows pass through this locator.

internal/helm/client.go[2925-2948]
internal/helm/client.go[3410-3421]
internal/helm/client.go[3708-3713]
internal/helm/client.go[3897-3907]
internal/helm/oci_sources.go[16-22]
internal/helm/oci_sources.go[153-168]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
OCI chart pulls use the registry discovery client's five-second HTTP timeout, causing valid downloads to fail on slower networks or registries.
## Fix Focus Areas
- internal/helm/client.go[2941-2948]
- internal/helm/oci_sources.go[153-168]
## Recommended Fix
Create separate registry-client construction paths for discovery and chart pulls. Retain the five-second timeout for tag discovery, but give chart pulls an appropriately longer or configurable timeout and add a test proving the pull path does not inherit `ociProbeTimeout`.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

2. HTTP fallback comment records history 📘 Rule violation ⚙ Maintainability

Description

The comment above httpClient.Get says to preserve the existing direct HTTP path, framing the
implementation in terms of its state before this change. It appears whenever maintainers inspect the
non-OCI download branch and can be rewritten as a timeless explanation of why Helm's downloader is
unsuitable.

Code

internal/helm/client.go[R3909-3911]

+		// Preserve the existing direct HTTP path. Helm's ChartDownloader loads all
+		// locally registered indexes and can fail because an unrelated cache entry
+		// is stale or missing.

Evidence

Rule 3036538 prohibits change-history references in added code comments. The added comment
characterizes the branch as preserving the existing path instead of stating only its lasting
technical rationale.

Rule 3036538: Disallow references to tickets or PR history in code comments
internal/helm/client.go[3909-3911]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The comment describes the direct HTTP path as `existing`, recording change history rather than only the enduring reason for the implementation.
## Fix Focus Areas
- internal/helm/client.go[3909-3911]
## Recommended Fix
Rephrase the comment without historical wording, for example: `Use direct HTTP because Helm's ChartDownloader loads all locally registered indexes and can fail when an unrelated cache entry is stale or missing.`

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

3. Tagged chart references become invalid ✓ Resolved 🐞 Bug ≡ Correctness

Description

resolveOCIChartURL recognizes a complete chart reference only when the raw source ends with /,
without accounting for a tag or digest suffix. A source such as oci://registry/acme/widget:1.2.3
or oci://registry/acme/widget@sha256:… therefore becomes …/widget:1.2.3/widget or
…/widget@sha256:…/widget in both detail and install flows.

Code

internal/helm/client.go[R2919-2922]

+	if strings.HasSuffix(source, "/"+chartName) {
+		return source, nil
+	}
+	return source + "/" + chartName, nil

Evidence

The resolver's suffix check and append operation directly produce the malformed paths for tagged and
digested sources. Both direct detail and both installation implementations invoke this resolver for
every caller-provided OCI repository, while InstallRequest exposes the repository and chart name
as separate unrestricted fields.

internal/helm/client.go[2906-2923]
internal/helm/client.go[3410-3418]
internal/helm/client.go[3571-3581]
internal/helm/client.go[3758-3768]
internal/helm/types.go[371-379]
internal/helm/handlers.go[1087-1120]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
Complete OCI chart references carrying a tag or digest are mistaken for repository prefixes, so the chart name is appended a second time.
## Fix Focus Areas
- internal/helm/client.go[2906-2923]
- internal/helm/oci_install_test.go[56-74]
- internal/helm/oci_install_test.go[114-158]
## Recommended Fix
Parse the final OCI path component structurally and compare the chart name after separating any tag or digest. Preserve already-complete references, define how an embedded tag interacts with the separate version argument, and add detail and install tests for tagged and digested inputs.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

Tip of the day

💡 Did you know, you can route each action level your way: inline, summary, both, or drop

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗

[qodo-free-for-open-source-projects]

2. Http fallback comment records history 📘 Rule violation ⚙ Maintainability

The comment above httpClient.Get says to preserve the existing direct HTTP path, framing the
implementation in terms of its state before this change. It appears whenever maintainers inspect the
non-OCI download branch and can be rewritten as a timeless explanation of why Helm's downloader is
unsuitable.

Agent Prompt

## Issue description
The comment describes the direct HTTP path as `existing`, recording change history rather than only the enduring reason for the implementation.

## Fix Focus Areas
- internal/helm/client.go[3909-3911]

## Recommended Fix
Rephrase the comment without historical wording, for example: `Use direct HTTP because Helm's ChartDownloader loads all locally registered indexes and can fail when an unrelated cache entry is stale or missing.`

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

[nadaverell]

LGTM, tested live. made one tiny fix to handling "latest" + test for it.

Thanks for the PR!