| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
Sorry, something went wrong.
A crash-looping pod's restart CPU burn reads as CPU load, so the HPA this CLI attached to every deployment scaled the failure to maxReplicas, then froze there once the metrics went missing. Keep the autoscaling block so an environments.yaml opt-in still deep-merges onto the existing replica bounds and CPU target. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
| Back | FazBrowse Home | New Git URL |
Important
Pending Mohammad's self-review. This note is removed by a human, not automation.
This CLI gave every deployment an HPA, so a crash-looping pod's restart CPU burn read as load, scaled it to maxReplicas, and froze there. Four of its releases account for 39 of 49 crash-looping pods on dev-sgp.
scaleapi/scaleapi#157885 fixes the same default on the backend cloud-deploy path. This PR is the CLI path.
cc @danielmillerp @RoxyFarhad @smoreinis @MichaelSun48 @declan-scale, this repo has no CODEOWNERS so the PR needs routing.
Test plan
Greptile Summary
The PR makes CLI-generated agent and Temporal worker autoscaling opt-in while retaining default replica and CPU bounds for explicit opt-ins.
Confidence Score: 5/5
The PR appears safe to merge, with the implementation, generated configuration guidance, and tests aligned on autoscaling being disabled unless explicitly enabled.
The recursive Helm-value merge preserves default bounds for partial opt-ins, the agent and Temporal worker remain independently configurable, and no concrete changed-code failure remains.
Important Files Changed
Reviews (1): Last reviewed commit: "fix(cli): make agent autoscaling opt-in ..." | Re-trigger Greptile
Context used: