fix(drupal): centralize template validation#662
Conversation
Standards Check (GR-079) — PASSEvery changed chart fully passes standards-check. |
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (3)
🚧 Files skipped from review as they are similar to previous changes (1)
📝 WalkthroughWalkthroughAdds a new ChangesValidation template and coverage
Estimated code review effort: 2 (Simple) | ~10 minutes 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
🟢 Security Scan:
|
| Framework | Score |
|---|---|
| MITRE + NSA + SOC2 | 83.333336% |
✅ Security posture acceptable.
There was a problem hiding this comment.
🧹 Nitpick comments (2)
charts/drupal/tests/validation_test.yaml (1)
47-53: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winTest coverage only covers one of the three reserved labels.
Only
app.kubernetes.io/componentoverride is tested;app.kubernetes.io/nameandapp.kubernetes.io/instanceoverrides aren't exercised. Given the near-identical logic, adding two more cases would fully cover the validation branches.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@charts/drupal/tests/validation_test.yaml` around lines 47 - 53, The validation tests for reserved pod label overrides only cover one branch, so add two more negative test cases in the same validation suite to exercise the other reserved labels. Extend the existing failedTemplate coverage around the podLabels validation logic to assert that overriding app.kubernetes.io/name and app.kubernetes.io/instance also returns the expected error messages, alongside the current app.kubernetes.io/component case.charts/drupal/templates/_helpers.tpl (1)
386-395: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winConsider deduplicating the reserved-label checks.
The three
hasKey/failblocks are structurally identical aside from the key name. A loop over the reserved keys would reduce duplication and make adding future reserved labels (e.g., ifapp.kubernetes.io/componenthandling changes) a one-line change.♻️ Proposed DRY refactor
{{- $podLabels := .Values.podLabels | default dict -}} -{{- if hasKey $podLabels "app.kubernetes.io/name" -}} -{{- fail "podLabels must not override selector label app.kubernetes.io/name" -}} -{{- end -}} -{{- if hasKey $podLabels "app.kubernetes.io/instance" -}} -{{- fail "podLabels must not override selector label app.kubernetes.io/instance" -}} -{{- end -}} -{{- if hasKey $podLabels "app.kubernetes.io/component" -}} -{{- fail "podLabels must not override selector label app.kubernetes.io/component" -}} -{{- end -}} +{{- range list "app.kubernetes.io/name" "app.kubernetes.io/instance" "app.kubernetes.io/component" }} +{{- if hasKey $podLabels . -}} +{{- fail (printf "podLabels must not override selector label %s" .) -}} +{{- end -}} +{{- end -}}🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@charts/drupal/templates/_helpers.tpl` around lines 386 - 395, The reserved-label validation in the _helpers.tpl logic is duplicated across three nearly identical hasKey/fail checks. Refactor the podLabels guard to iterate over the reserved selector keys used by the label helpers (app.kubernetes.io/name, app.kubernetes.io/instance, app.kubernetes.io/component) and fail with the same message when any are present, so future reserved labels can be added in one place.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Nitpick comments:
In `@charts/drupal/templates/_helpers.tpl`:
- Around line 386-395: The reserved-label validation in the _helpers.tpl logic
is duplicated across three nearly identical hasKey/fail checks. Refactor the
podLabels guard to iterate over the reserved selector keys used by the label
helpers (app.kubernetes.io/name, app.kubernetes.io/instance,
app.kubernetes.io/component) and fail with the same message when any are
present, so future reserved labels can be added in one place.
In `@charts/drupal/tests/validation_test.yaml`:
- Around line 47-53: The validation tests for reserved pod label overrides only
cover one branch, so add two more negative test cases in the same validation
suite to exercise the other reserved labels. Extend the existing failedTemplate
coverage around the podLabels validation logic to assert that overriding
app.kubernetes.io/name and app.kubernetes.io/instance also returns the expected
error messages, alongside the current app.kubernetes.io/component case.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro Plus
Run ID: 4b705251-d751-4df7-a272-bace6f73e63e
📒 Files selected for processing (3)
charts/drupal/templates/_helpers.tplcharts/drupal/templates/validate.yamlcharts/drupal/tests/validation_test.yaml
ce2e833 to
ad8595c
Compare
ad8595c to
ada9814
Compare
|
Addressed both CodeRabbit review-summary nitpicks. Changes:
Validation:
Note: these CodeRabbit items were posted in the review summary/body, not as active review threads, so there are no thread IDs to reply to or resolve for them. |
Summary
drupal.validatehelper andtemplates/validate.yamlentrypointValidation
Site PR: helmforgedev/site#341
Issue: #633
Summary by CodeRabbit
New Features
Tests