CI: stop using spot-instances, they are flaky#593
Conversation
|
|
|
Warning Rate limit exceeded
To continue reviewing without waiting, purchase usage credits in the billing tab. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Pro Run ID: 📒 Files selected for processing (1)
WalkthroughThis pull request disables GCP preemptible instances in two deployment tasks within the pipeline configuration. The Suggested reviewers
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ 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 |
There was a problem hiding this comment.
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
ci/pipelines/builder.yml (1)
577-594:⚠️ Potential issue | 🟡 Minor | ⚡ Quick win
VARS_PREEMPTIBLE: truestill enables spot instances for BATs test VMsThe
prepare-batstask at line 586 still passesVARS_PREEMPTIBLE: trueinto the BATs configuration. This controls whether the VMs deployed by BOSH during the BAT test run are preemptible — meaning the actual test VMs remain spot instances and are still subject to the same preemption-driven flakiness the PR is addressing. Only the director was switched to on-demand.🐛 Proposed fix
- VARS_PREEMPTIBLE: true + VARS_PREEMPTIBLE: false🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@ci/pipelines/builder.yml` around lines 577 - 594, The prepare-bats task is still passing VARS_PREEMPTIBLE: true which makes the BATs-deployed test VMs preemptible; change the VARS_PREEMPTIBLE value to false in the prepare-bats task so BATs creates on‑demand (non‑preemptible) VMs during the test run (update the VARS_PREEMPTIBLE entry in the same prepare-bats block to false to match the director change).
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Outside diff comments:
In `@ci/pipelines/builder.yml`:
- Around line 577-594: The prepare-bats task is still passing VARS_PREEMPTIBLE:
true which makes the BATs-deployed test VMs preemptible; change the
VARS_PREEMPTIBLE value to false in the prepare-bats task so BATs creates
on‑demand (non‑preemptible) VMs during the test run (update the VARS_PREEMPTIBLE
entry in the same prepare-bats block to false to match the director change).
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
Run ID: 45f6892d-d24a-4e67-8b79-51b751b45f27
📒 Files selected for processing (1)
ci/pipelines/builder.yml
There was a problem hiding this comment.
Pull request overview
This PR aims to improve CI stability by disabling GCP preemptible (spot) instances in the builder pipeline, reducing job flakiness during integration testing.
Changes:
- Set
GCP_PREEMPTIBLE: falsefor the GCPdeploy-directortask used by IPv4 stemcell tests. - Set
GCP_PREEMPTIBLE: falsefor the GCPdeploy-directortask used by BATS stemcell tests.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
These are not stable enough for testing purposes.
2c6bc72 to
0bf1a42
Compare
These are not stable enough for testing purposes.
NOTE: this repository uses a "Merge Forward" strategy
Changes should be made in the earliest applicable branch, and
merged forward through subsequent branches.
ubuntu-<short_name>)merge-to-<next_short_name>branchubuntu-<short_name>intomerge-to-<next_short_name>merge-to-<next_short_name>intoubuntu-<next_short_name>