fix: redis.external.existingSecret fails with helm template in Kustomize (client-side render)

[BobVanB]

Bug: redis.external.existingSecret fails with helm template in Kustomize (client-side render)

Summary

When Harbor is rendered via Kustomize Helm integration (kustomize build --enable-helm / helm template in a CI/client-side context), setting redis.external.existingSecret causes template rendering to fail with a nil-pointer error.

This blocks a valid use case where credentials must come from Kubernetes Secrets at runtime (not at template time).

---

Environment

• Harbor Helm chart: 1.18.2
• Render path: Kustomize Helm integration (client-side rendering)
• Command executed by Kustomize (from logs):
  • helm template ... -f harbor-kustomize-values.yaml -f harbor.yaml ...

---

Minimal values to reproduce

redis:
  type: external
  external:
    addr: "redis.example:6379"
    existingSecret: "harbor-redis-auth"
    # username/password intentionally not set (runtime secret use)

---

Actual behavior

Rendering fails with a nil-pointer in helper/template chain when chart tries to resolve Redis password from secret during template render.

Error excerpt:

   Error: coalesce.go:298: warning: cannot overwrite table with non table for harbor.expose.route.parentRefs (map[])
Error: template: harbor/templates/trivy/trivy-sts.yaml:29:28: executing "harbor/templates/trivy/trivy-sts.yaml" at <include (print $.Template.BasePath "/ "/trivy/trivy-secret.yaml") .>: error calling include: template: harbor/templates/trivy/trivy-secret.yaml:11:15: executing "harbor/templates/trivy/tr-seivy-secret.yaml" at <include "harbor.redis.urlForTrivy" .>: error calling include: template: harbor/templates/_helpers.tpl:246:48: executing "harbor.rrlFedis.urlForTrivy" at <include "harbor.redis.url" $>: error calling include: template: harbor/templates/_helpers.tpl:214:64: executing "harbor.redis.urclul" at <include "harbor.redis.cred" $>: error calling include: template: harbor/templates/_helpers.tpl:203:73: executing "harbor.redis.cred" at <includdise "harbor.redis.pwdfromsecret" $>: error calling include: template: harbor/templates/_helpers.tpl:197:56: executing "harbor.redis.pwdfromsecret" at <.terValues.redis.external.existingSecret>: nil pointer evaluating interface {}.REDIS_PASSWORD

Use --debug flag to render out invalid YAML
: unable to run: 'helm template harbor ~/git/ams-tools/cps2/ams-system-harbor/overlays/vdc-sbx-gp/charts/harbor-1.18.2/harbor --namespace ams-ms-system-harbor -f /tmp/kustomize-helm-1112470667/harbor-kustomize-values.yaml -f ~/git/ams-tools/cps2/ams-system-harbor/overlays/vdc-sbx-valgp/values/harbor.yaml -f ~/git/ams-tools/cps2/ams-system-harbor/base/harbor/components/kvk-ca-bundle/values.yaml' with env=[HELM_CONFIG_HOM/kuE=/tmp/kustomize-helm-1112470667/helm HELM_CACHE_HOME=/tmp/kustomize-helm-1112470667/helm/.cache HELM_DATA_HOME=/tmp/kustomize-helm-1112470667/helm/.d'heata] (is 'helm' installed?): exit status 1
No resources found

(There is also a coalesce warning about expose.route.parentRefs, but that appears unrelated to the fatal error.)

---

Expected behavior

helm template should succeed in client-side/Kustomize mode when redis.external.existingSecret is set, without requiring:

1. live cluster secret lookup at render time, or
2. inline redis username/password values.

Credentials should be consumed via secretKeyRef at runtime.

---

Why this is a bug

For GitOps/Kustomize workflows, rendering is intentionally done without cluster access to runtime secrets.
Requiring secret contents at template time breaks this workflow and prevents secure secret handling.

---

Proposed fix

When redis.type=external and redis.external.existingSecret is set:

1. Do not resolve secret data during template rendering (no lookup-dependent credential construction for URLs).
2. Use runtime env refs (valueFrom.secretKeyRef) for REDIS_USERNAME / REDIS_PASSWORD.
3. Build runtime redis URLs using env placeholders (e.g. $(REDIS_USERNAME):$(REDIS_PASSWORD)), or avoid embedding credentials in rendered secrets entirely.
4. Keep current redis.external.username/password behavior only as fallback when existingSecret is not set.

---

Acceptance criteria

• helm template succeeds with redis.external.existingSecret in a no-cluster client-side render.
• Kustomize Helm integration succeeds with same values.
• Existing non-existingSecret flows remain backward-compatible.
• Unit tests cover:
  • external + existingSecret + client-side render path,
  • fallback path without existingSecret.

---

Additional context

This issue impacts GitOps pipelines that use Kustomize+Helm and rely on runtime secret injection for Redis credentials.

[github-actions]

This PR is being marked stale due to a period of inactivty. If this PR is still relevant, please comment or remove the stale label. Otherwise, this PR will close in 30 days.