fix: make health_checks optional in service deployment module#520
Conversation
health_checks is not required by the application/2.0 helm chart template. The template guards probe generation with hasKey checks and uses default values throughout - missing health_checks simply results in no probes configured, which is a valid deployment state. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
💤 Files with no reviewable changes (1)
WalkthroughRemoved Changes
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
📝 Coding Plan
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 Tip CodeRabbit can scan for known vulnerabilities in your dependencies using OSV Scanner.OSV Scanner will automatically detect and report security vulnerabilities in your project's dependencies. No additional configuration is required. |
…ti-affinity optional (#555) Two module-schema bugs that caused false-positive pre-flight validation errors (raptor create release) while the platform/Deployer accepts the specs fine. mongo/k8s/0.2: the size schema declared `cpu`/`memory` (required), but the v0.2 Terraform (facets-iac .../1_input_instance/mongodb/main.tf) reads `cpu_requests`/`memory_requests` behind a `contains(keys, "cpu_requests")` guard. The `cpu`/`memory` naming only belongs to the 0.3 TF. As a result a blueprint following the 0.2 schema would silently get NO resource requests, and a correct blueprint (using cpu_requests/memory_requests, as prod does) fails validation with "spec.size.memory required field is missing". Rename the request fields to cpu_requests/memory_requests so the schema matches the v0.2 module and real usage; limit fields and their x-ui-compare refs updated to match. service/deployment/0.1: `enable_host_anti_affinity` was in the spec `required` list with no default, but the shared app-chart helm template guards it with `hasKey` and treats absence as "no anti-affinity". The field is behaviorally optional, so requiring it rejects valid specs (e.g. service/control-plane-ui). Remove it from `required` (kept in properties and x-ui-order). Follows the precedent of #520 (health_checks made optional). Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Description
The health_checks is not required by the 3_utility/application/ helm chart template. The template guards probe generation with hasKey checks and uses default values throughout - missing health_checks simply results in no probes configured, which is a valid deployment state.
Related issues
Type of change
Checklist
developbranchTesting
Reviewer instructions
Summary by CodeRabbit