fix(ci): drop redundant api pod readiness wait in helm e2e#18
fix(ci): drop redundant api pod readiness wait in helm e2e#18lewisjared wants to merge 2 commits into
Conversation
The "Validate API" step ran `kubectl wait --for=condition=Ready pod -l app.kubernetes.io/component=api` right after `kubectl rollout status`. `rollout status` already blocks until the new pod is Ready, and the extra wait re-selects every pod matching the label — including the old pod that `rollout restart` is terminating. A terminating pod never reaches Ready, so the wait timed out even though the rollout succeeded and the API was serving traffic, failing the job intermittently. Remove the redundant wait; `rollout status` is the readiness gate, and api_check.py already retries endpoint flaps.
|
Warning Review limit reached
Next review available in: 58 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughThe packaging workflow's "Validate API can read compute results" step was modified to remove a ChangesWorkflow rollout check update
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
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 |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
🧹 Nitpick comments (1)
.github/workflows/packaging.yaml (1)
195-195: 📐 Maintainability & Code Quality | 🔵 Trivial | 💤 Low valueMinor: double space in
kubectl rollout statuscommand.Line 195 has a double space between
statusanddeployment. Harmless for kubectl but worth tidying for consistency.✏️ Proposed fix
- kubectl rollout status deployment/test-climate-ref-aft-api --timeout=300s + kubectl rollout status deployment/test-climate-ref-aft-api --timeout=300s
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro Plus
Run ID: 40c7bbcc-a4fa-4a8d-9249-92fa849e1fd9
📒 Files selected for processing (1)
.github/workflows/packaging.yaml
1 participant
The
Test Helm Deploymentjob (packaging workflow) fails intermittently at the Validate API step, even though the API is healthy and serving traffic.Cause
The step runs:
kubectl rollout restart deployment/test-climate-ref-aft-api kubectl rollout status deployment/test-climate-ref-aft-api --timeout=300s kubectl wait --for=condition=Ready pod -l app.kubernetes.io/component=api --timeout=60skubectl rollout statusalready blocks until the rollout is complete — i.e. the new pod isReady. The subsequentkubectl wait --for=condition=Ready pod -l ...then re-selects all pods carrying thecomponent=apilabel, which for a short window afterrollout restartstill includes the old, terminating pod. A terminating pod never reachesReady, so the wait times out and fails the job — while the rollout has actually succeeded and the API is up.Observed in three consecutive runs on a version-bump branch: the deployment reported
1 available | 0 unavailable,Available: True, "successfully rolled out", the API logged "Application startup complete" and servedGET /health-check/ -> 200throughout, yetkubectl waittimed out listing both the old-replicaset and new-replicaset pods.Fix
Drop the redundant
kubectl wait.rollout statusis the readiness gate, andapi_check.pyalready retries endpoint flaps during the rollout, so nothing downstream needs the extra wait.Pure CI-reliability change; no application or chart behaviour is affected.
Summary by CodeRabbit