chore(helm): define pod probes

[adamantal]

Description

When robusta starts, the pod becomes healthy immediately. After a few seconds, it loads the config and the pydantic validations run on those configs. If there's an error, the container can immediately fail leaving no running robusta pod behind (not good).

If we want to make sure the rolling our a new version is graceful, we can define a readiness probe or even just a bit of a delay (to wait a few seconds until robusta loads the configs, making sure there's no validation error here).

Testing

Currently in progress

[coderabbitai]

Walkthrough

The pull request adds health probe configurations (liveness and readiness probes) to the Helm chart's runner container deployment, enabling HTTP health checks on port 5000 at the /healthz endpoint. A container port definition is also introduced.

Changes

Cohort / File(s)	Summary
Health probes and port configuration helm/robusta/templates/runner.yaml, helm/robusta/values.yaml	Introduces conditional livenessProbe and readinessProbe sections in the runner container template, along with a port block (port 5000, protocol TCP, named "http"). Corresponding probe configurations are added to values.yaml with HTTP checks at /healthz, enabled status, and timing parameters (initialDelaySeconds, periodSeconds, timeoutSeconds, failureThreshold).

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~5 minutes

• Straightforward addition of standard Kubernetes health probe configurations
• Configuration changes follow established patterns in the Helm chart
• Limited scope with no complex logic or control flow modifications

Pre-merge checks and finishing touches

✅ Passed checks (3 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title 'chore(helm): define pod probes' accurately summarizes the main change, which adds readiness and liveness probes to the Helm chart.
Description check	✅ Passed	The description clearly explains the problem (pod becomes healthy before config validation) and the solution (adding probes), directly relating to the changeset.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

✨ Finishing touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment

---

📜 Recent review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 282abd6 and a5fa727.

📒 Files selected for processing (2)

• helm/robusta/templates/runner.yaml (2 hunks)
• helm/robusta/values.yaml (1 hunks)

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)

• GitHub Check: run_tests

🔇 Additional comments (3)

helm/robusta/values.yaml (1)

742-762: Verify that the Robusta application exposes the /healthz endpoint on port 5000.

The probe configurations assume a /healthz HTTP endpoint exists on port 5000. Since the PR description mentions testing is still in progress, please confirm:

1. The /healthz endpoint is implemented in the Robusta runner application
2. It responds correctly during the startup configuration-loading phase (returns 503/non-2xx until ready)
3. It responds with 200 once configuration is loaded and validated
4. The endpoint is performant enough to complete within the 5-second timeout

The probe values themselves look well-configured for the stated use case (preventing premature health before configuration loads).

helm/robusta/templates/runner.yaml (2)

71-74: Port definition is well-structured.

Explicitly defining the container port with a name (http) is a Kubernetes best practice. This allows future port references by name for improved maintainability.

Note: The Service definition (line 295) currently references targetPort: 5000 by number rather than by the port name. This works correctly but for consistency consider using targetPort: http (though not required).

---

175-182: Probe conditionals use the correct Helm templating pattern.

The conditional rendering correctly:

• Checks both that the probe configuration exists AND the enabled flag is true
• Uses the omit function to exclude the enabled field from rendered YAML (not part of the Kubernetes Probe API)
• Falls back safely if the configuration is missing or disabled

The implementation aligns properly with the probe configurations in values.yaml.

Tip

📝 Customizable high-level summaries are now available in beta!

You can now customize how CodeRabbit generates the high-level summary in your pull requests — including its content, structure, tone, and formatting.

• Provide your own instructions using the high_level_summary_instructions setting.
• Format the summary however you like (bullet lists, tables, multi-section layouts, contributor stats, etc.).
• Use high_level_summary_in_walkthrough to move the summary from the description to the walkthrough section.

Example instruction:

"Divide the high-level summary into five sections:

1. 📝 Description — Summarize the main change in 50–60 words, explaining what was done.
2. 📓 References — List relevant issues, discussions, documentation, or related PRs.
3. 📦 Dependencies & Requirements — Mention any new/updated dependencies, environment variable changes, or configuration updates.
4. 📊 Contributor Summary — Include a Markdown table showing contributions:
   | Contributor | Lines Added | Lines Removed | Files Changed |
5. ✔️ Additional Notes — Add any extra reviewer context.
   Keep each section concise (under 200 words) and use bullet or numbered lists for clarity."

Note: This feature is currently in beta for Pro-tier users, and pricing will be announced later.

---

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.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}