Repository navigation
feat(chart): add startup probes to the API, frontend and database - #668
Merged
Merged
Conversation
Without a startup probe, a slower start after an image update gets the container killed by its liveness probe instead of given time to boot. Each container now has a startup probe on the same endpoint as its readiness probe, as in quickstart-openshift. Refs #597
There was a problem hiding this comment.
🟡 Changes recommended
The API startup allowance is shorter than the database allowance despite API startup depending on MongoDB.
1 open finding
What changed in this PR
Adds configurable startup probes to prevent premature container restarts during boot.
Changes:
- Renders startup probes for API, frontend, and database containers.
- Configures HTTP and TCP startup checks with component-specific allowances.
| File | Description |
|---|---|
charts/pubcode/values.yaml |
Defines startup probe settings. |
charts/pubcode/templates/api/templates/deployment.yml |
Renders API startup probes. |
charts/pubcode/templates/frontend/templates/deployment.yaml |
Renders frontend startup probes. |
charts/pubcode/templates/database/templates/sfs.yml |
Renders database startup probes. |
🧠 Review effort: Balanced
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
The API binds its port only after connecting to MongoDB, whose startup probe allows 5 minutes, so the API now allows 6. Refs #597
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
The chart's containers have no startup probes, so if an auto-merged image update makes a container start more slowly, its liveness probe kills it before it finishes booting.
Refs #597
Changes
The API, frontend and database templates render
startupProbewhen a container sets one. This uses the same pass-through pattern as the existing readiness and liveness probes.values.yamlsets a startup probe on each container, using the same endpoint as its readiness probe:/api/pub-code/healthon port 3000/healthon port 3001The frontend timing matches quickstart-openshift. MongoDB gets up to 5 minutes, since it can take longer to start on a large volume. The API gets 6 minutes, because it opens its port only after connecting to MongoDB.
Readiness and liveness probes are unchanged; Kubernetes starts them once the startup probe succeeds.
helm lintpasses andhelm templaterenders all three probes. This PR's deployment exercises them in CI.Thanks for the PR!
Deployments, as required, will be available below:
Please create PRs in draft mode. Mark as ready to enable:
After merge, new images are deployed in: