Bug | repo-server-api: remote `chart:` source whose `$values` come from the same repo as `--repo` fails to render

[jgarces-openspace]

Describe the bug

With --render-method repo-server-api, a multi-source Application fails to render when a remote Helm chart: source reads its Helm value files ($ref) from a source that lives in the same repository passed to --repo. The render aborts the whole environment.

This is related to, but distinct from, #426 / #428: there the $ref source was in a different repository. Here the $ref source is in the same repo as --repo, but it is consumed by a remote chart: source. When the ref-consuming source is a local path: chart it works (the tool streams the ref files locally); when it's a remote chart: there are no local files to stream, so the tool falls back to the remote RPC and points the repo server at the real git remote — at the tool's local working branch (-b / -t), which doesn't exist on the remote (and the repo may be private). The clone fails.

Expected behavior

some-chart is rendered using envs/common/some-chart-values.yaml from the PR's checkout of org/charts (so value-file changes in the PR show up in the diff) — the same way the local-path: variant already works today.

Standard output (with --debug flag)

🤖 Rendering application source via repo server (App: "example [...]") (multiSource: true) (remoteChart: true) (sourceIndex: 1)
❌ Failed to render application via repo server: error="failed to render app example [...]: repo server returned error for content source 1: rpc error: code = Unknown desc = failed to get git client for repo https://github.com/org/charts.git: ..."
❌ Failed to extract resources
💥 Deleting cluster...
💥 Cluster deleted successfully
❌ failed to get resources: failed to process applications

With a private --repo, the same failure presents as an auth/clone error; supplying repo credentials via --secrets-folder does not help, because the requested revision — the tool's local -b / -t working branch — doesn't exist on the remote at all, so there is nothing to authenticate against.

Application causing problems (if applicable)

Fails — a remote chart: source whose helm.valueFiles read from a $ref source in the same repo as --repo:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: example
  namespace: argocd
spec:
  project: default
  destination:
    namespace: example
    server: https://kubernetes.default.svc
  sources:
    # ref source in the SAME repo as --repo (a real branch, e.g. main)
    - repoURL: https://github.com/org/charts.git
      targetRevision: main
      ref: values
    # remote Helm chart whose value file is read from the $ref above
    - repoURL: https://charts.example.io
      chart: some-chart
      targetRevision: 1.2.3
      helm:
        valueFiles:
          - $values/envs/common/some-chart-values.yaml

(envs/common/some-chart-values.yaml exists in org/charts.)

For contrast, this works today — same $ref, but consumed by a local path: chart, so the tool streams the ref files locally:

  sources:
    - repoURL: https://github.com/org/charts.git
      targetRevision: main
      ref: values
    - repoURL: https://github.com/org/charts.git
      path: charts/my-chart
      targetRevision: main
      helm:
        valueFiles:
          - $values/envs/common/my-chart-values.yaml

Parameters

✨ Running with:
✨ - render-method: repo-server-api
✨ - base-branch: main
✨ - target-branch: pr
✨ - argocd-namespace: argocd
✨ - repo: org/charts
✨ - redirect-target-revisions: [main]

Your pipeline (if applicable)

docker run --rm --network host \
  -v /var/run/docker.sock:/var/run/docker.sock \
  -v "$PWD/base-branch:/base-branch" \
  -v "$PWD/target-branch:/target-branch" \
  -v "$PWD/output:/output" \
  dagandersen/argocd-diff-preview:v0.2.8 \
  --repo org/charts -b main -t pr \
  --render-method repo-server-api

---

Root cause (from reading the source)

In pkg/reposerverextract/extract.go, buildManifestRequestForSource short-circuits to the remote RPC when the content source is a remote chart:

if primarySource.Chart != "" {
    request = newManifestRequest(&primarySource)
    request.RefSources = buildRefSourcesMap(refSources, creds)
    return request, "", nil, nil  // remote RPC; streamDir=""
}

buildRefSourcesMap builds RefTarget{Repo: <same repo>, TargetRevision: ref.TargetRevision}. By this point RedirectSources has rewritten that same-repo ref's targetRevision to the local working branch (-b / -t), which doesn't exist on the remote — so the repo server's git fetch fails. Even without the redirect it would fetch the remote's copy of the value file rather than the PR's, so a PR that changes the value file wouldn't be reflected.

The existing local file-streaming path (used when the primary is a local path:) already copies $ref directories into the request and rewrites $ref/… value-file paths to relative paths — it just isn't reachable when the primary is a remote chart.

Suggested directions

1. Serve same-repo $ref sources from the local working tree. When a $ref source's repoURL matches --repo, stand up a throwaway local git remote hosting the -b / -t branches and point RefTarget.Repo at it. This fixes both the clone failure and value-file fidelity, and reuses the existing redirect of targetRevision to the local branch.
2. Or helm pull the remote chart and use GenerateManifestWithFiles, injecting the same-repo $ref files from the local checkout exactly as the local-path: path already does.

Happy to help test against a reproducible setup.

Note: this report was prepared with AI assistance.