Concurrency group issues with block/input steps

[pzeballos]

There's a known issue when using concurrency group with block/input steps.

The time-ordering of jobs that reference a concurrency is stable (roughly: the build creation time, and then the jobs ordering within that build). But only active jobs (roughly: running or eligible-to-run) are part of the queue. Jobs waiting for a block/input step aren’t active, so they’re not active in the queue, and so the concurrency group will let jobs from a newer build run. But then when you unblock that block/input step, those jobs become active in the queue, and potentially jump in front of the newer build, breaking the concurrency group ordering.

[buildkite-docs-bot]

Preview URL: https://2620--bk-docs-preview.netlify.app

[gilesgas]

Quick question, does the concurrency attribute defined in a step specify the concurrency limit for that step?

[pzeballos]

Quick question, does the concurrency attribute defined in a step specify the concurrency limit for that step?

You need to specify it. For example concurrency: 1 will set the limit to 1. If you don't put anything, it's like doing nothing :)