Fix existingSecret path in Helm deployment template - #10313
Conversation
…-org#10214) The annotation conditions referenced the non-existent top-level .Values.existingSecret instead of .Values.auth.existingSecret, so the secret checksum annotation and the empty-secret gating never worked as intended when an existing secret wasn't supplied.
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
Included review availability: Your plan provides up to 8 included reviews per hour; 6 remain after this review. WalkthroughThe Helm deployment template now checks ChangesHelm secret configuration
Estimated code review effort: 2 (Simple) | ~5 minutes Merge Risk: ⚪ Minimal · up to This change corrects the existing-secret value path used by deployment annotations and secret gating. The behavior is localized, and no actionable merge-blocking risk remains after normal checks and review. Suggested reviewers: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Summary
deployment.yaml's annotation conditions referenced the non-existent top-level.Values.existingSecretinstead of.Values.auth.existingSecret, so the secret checksum annotation and the empty-secret gating never worked as intended when an existing secret wasn't supplied.secret.yamlalready uses the correct.Values.auth.existingSecretpath.Fixes #10214.
Test plan
existingSecretreference across the chart's templates and values.yaml to confirm.Values.auth.existingSecretis the only path that actually existshelm lint/helm template(not available in this environment; the change is a straightforward path correction matching the existing pattern used elsewhere in the same file)Summary by CodeRabbit