Repository navigation
(P4DEVOPS-15381) Fix ABS priority: CI runs no longer request priority 1 - #294
Conversation
There was a problem hiding this comment.
Pull request overview
Updates ABS provisioning priorities to prevent CI jobs from bypassing pool limits.
Changes:
- Assigns priority 3 to CI requests and 2 otherwise.
- Adds tests for
CI=trueandCI=false.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.
| File | Description |
|---|---|
tasks/abs.rb |
Updates ABS priority selection. |
spec/tasks/abs_spec.rb |
Adds priority behavior tests. |
Suppressed comments (1)
spec/tasks/abs_spec.rb:143
- This also uses
with_env, whose cleanup unconditionally deletesCIrather than restoring the runner's original value. The example therefore leaks a global environment change to later specs. Avoid mutating the real environment here, or make the helper restore each key's previous value.
with_env('CI' => 'false') do
expect(abs.task(**params)).to eq({ status: 'ok', nodes: 1 })
end
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
487b0da to
13f0bcb
Compare
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 2 out of 2 changed files in this pull request and generated no new comments.
Suppressed comments (1)
tasks/abs.rb:43
- AppVeyor CI is still classified as a local run here: this same method explicitly handles AppVeyor with
ENV['CI'] == 'True'above, so those requests will receive priority 2 rather than the documented CI priority 3. Compare the value case-insensitively (and add coverage forCI=True) so every supported CI provider gets the capped default priority.
priority = ENV['CI'] == 'true' ? 3 : 2
f45d336 to
1c2792a
Compare
|
@isaac-jha could you resolve conflicts? @actowery could someone take a look at this? Module CI is currently bypassing ABS capacity limits |
|
@isaac-jha If you could resolve the conflicts we can get this merged |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #294 +/- ##
=======================================
Coverage 91.31% 91.31%
=======================================
Files 7 7
Lines 518 518
=======================================
Hits 473 473
Misses 45 45 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
ca1e25e to
f2cbc09
Compare
`priority = ENV['CI'] ? 1 : 2` was always truthy because ENV['CI'] is a string (even "false" is truthy), so every CI run requested ABS priority 1. Priority 1 bypasses the ABS max_count cap, letting CI swamp the pool. Guard on the actual value so CI uses the lowest priority (3) and local/interactive runs use 2; neither claims priority 1. This is one of the sources of orphaned ABS VMs tracked in P4DEVOPS-15381. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
f2cbc09 to
f5afde7
Compare

Problem
tasks/abs.rbset the ABS request priority with:ENV['CI']is a string, so it is truthy for any value — including"false". Every run under CI (GitHub Actions always setsCI=true, and Litmus/module CI provisions through this task) therefore requested ABS priority 1.Per the ABS README, "Jobs at Priority 1 ignore max_count" — priority 1 bypasses the pool's anti-swamping cap. So this made CI able to flood ABS and contributed to VM pile-up/orphans.
This is one of the orphan sources tracked in P4DEVOPS-15381 (observed via the
complyci-ghactionsuser used bypuppetlabs/comply-e2e).Fix
CI=false/unset → priority 2.max_count.Tests
Added coverage asserting the posted
priorityis 3 underCI=trueand 2 underCI=false. Fullspec/tasks/abs_spec.rbpasses locally (13 examples, 0 failures).Note on reaping
This stops CI from bypassing
max_count, but the 12-hour ABS reaper backstop for these requests is being fixed separately inalways-be-scheduling(the reaper was scoped only touser == always-be-scheduling). See P4DEVOPS-15381.🤖 Generated with Claude Code