ci: use all heavy Buildkite workers - #60
Conversation
|
Bugbot is not enabled for your account, so this pull request was not reviewed. Enable Bugbot in the Cursor dashboard to get automatic reviews on future PRs. |
![devin-ai-integration[bot]](https://avatars.githubusercontent.com/in/811515?s=60&v=4){kind=small}
| if [[ "$(grep -Fc -- 'concurrency_group: "hetzner-linux-heavy-workloads"' <<<"$linux_buildkite_pipeline")" != 5 ]] || | ||
| [[ "$(grep -Fc -- 'concurrency: 2' <<<"$linux_buildkite_pipeline")" != 5 ]]; then | ||
| printf 'Buildkite Linux validation must leave one shared heavy worker available\n' >&2 | ||
| [[ "$(grep -Fc -- 'concurrency: 3' <<<"$linux_buildkite_pipeline")" != 5 ]]; then | ||
| printf 'Buildkite Linux validation must use all connected shared heavy workers\n' >&2 | ||
| exit 1 | ||
| fi |
There was a problem hiding this comment.
📝 Info: Contract test remains a brittle exact-count string match
The assertion counts literal concurrency: 3 occurrences and requires exactly 5 in the Linux portion of .buildkite/pipeline.yml. It is decoupled from concurrency_group, so a step with a different group but the same numeric value would still satisfy the count, and any added Linux step (or a step using a different limit) will fail the test with a message about worker capacity rather than the actual mismatch. Since the whole check is textual, it also silently passes if the pipeline is reformatted (e.g. inline flow mapping). Not a defect introduced here, but the maintenance burden grows each time the number changes; a YAML-aware assertion (parse steps, check each heavy-queue step's concurrency equals the connected agent count) would be more robust.
Was this helpful? React with 👍 or 👎 to provide feedback.
| concurrency: 3 | ||
| concurrency_group: "hetzner-linux-heavy-workloads" |
There was a problem hiding this comment.
🔍 Concurrency now equals the number of connected heavy agents, removing spare capacity
Raising each heavy step's concurrency to 3 means a single build can occupy all three heavy agents at once; the previous limit of 2 deliberately reserved one agent (per the old failure message "must leave one shared heavy worker available"). With no spare, unrelated queued jobs on hetzner-linux-heavy (e.g. a second PR build, or a manual/ops job) can be blocked until a long step such as the 60-minute harnesses step finishes. Worth confirming that no other pipeline or operational task depends on always having one free heavy agent.
Was this helpful? React with 👍 or 👎 to provide feedback.
1 participant
Summary
Test plan