ci: serialize Jenkinsfile runs via lockable-resource#147
Conversation
…time) Jenkins agent pool gets saturated when multiple PRs (or PR + master merge) run concurrently — each Jenkinsfile run launches 14 parallel stages, so two concurrent runs demand 28 executor slots. Add a global lock using the Lockable Resources plugin so only one pipeline run executes at a time across the whole repo (master + every PR branch). Tradeoff: queued runs wait their turn. With ~50-min build duration, 3 queued PRs serialize to ~2.5h wall-clock. If that's too slow, upgrade to the "Throttle Concurrent Builds" plugin with Max=2 instead (PR-level parallelism with a ceiling). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
Warning Rate limit exceeded
You’ve run out of usage credits. Purchase more 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. 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 |
1 participant
Why
Jenkins agent pool gets overloaded when multiple PRs run concurrently. Each Jenkinsfile run launches 14 parallel integration-test stages, so two concurrent runs demand 28 executor slots. The recent triple-PR situation (#143 + #145 + #146) tipped the pool.
What this PR does
Adds a single
lock(resource: 'dotnetworkqueue-ci')to the Jenkinsfile'soptionsblock. Uses the Lockable Resources plugin (already present in standard Jenkins installs). Effect: only ONE Jenkinsfile run executes anywhere in the repo at a time; second/third/etc. queue.Tradeoff
Serial queuing makes wall-clock time grow linearly with queue depth. With ~50-min builds, three queued PRs take ~2.5h end-to-end vs ~50min parallel. If that's too slow in practice, the follow-up upgrade is the "Throttle Concurrent Builds" plugin with
Max Total Concurrent Builds = 2(lets 2 PRs run in parallel, third waits).Test plan
Note
The PR itself ironically triggers one more concurrent build on top of the current queue (#143, #145). After merge, the throttle takes effect for all future runs.
🤖 Generated with Claude Code