You signed in with another tab or window.Reload to refresh your session.You signed out in another tab or window.Reload to refresh your session.You switched accounts on another tab or window.Reload to refresh your session.Dismiss alert
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.Learn more about bidirectional Unicode characters
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).
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 between282abd6 anda5fa727.
📒 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:
The/healthz endpoint is implemented in the Robusta runner application
It responds correctly during the startup configuration-loading phase (returns 503/non-2xx until ready)
It responds with 200 once configuration is loaded and validated
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 referencestargetPort: 5000 by number rather than by the port name. This works correctly but for consistency consider usingtargetPort: 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 theenabled flag is true
Uses theomit function to exclude theenabled 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 invalues.yaml.
Tip
📝 Customizable high-level summaries are now available in beta!
You can now customize how CodeRabbit generates thehigh-level summary in your pull requests — including its content, structure, tone, and formatting.
Provide your own instructions using thehigh_level_summary_instructions setting.
Format the summary however you like (bullet lists, tables, multi-section layouts, contributor stats, etc.).
Usehigh_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:
📝 Description — Summarize the main change in 50–60 words, explaining what was done.
📓 References — List relevant issues, discussions, documentation, or related PRs.
📦 Dependencies & Requirements — Mention any new/updated dependencies, environment variable changes, or configuration updates.
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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