Concurrency Limit Behavior and Concurrency Gates

General
1

A few questions related to:

Simplified, the jobs which are part of a concurrency group within a single build which are eligible to run must all finish before another build’s jobs in that concurrency group are permitted to run.

  1. How do concurrency gates work when the concurrency_limit is greater than 1? If it’s set to 3, does that allow 3 separate builds to be in the gated section at the same time.
  2. If a block step in the middle of a concurrency gate is never unblocked, is there one less “concurrent capacity” for the entire group until the build is cancelled, or does the block step disrupt the gate (and if so, does that only happen if the step is blocked once reached)?
  3. If, while within a gated section, a dynamic pipeline injects new steps that are part of the same concurrency group, is the “gate” adjusted to include those new steps, and to protect any new non-intermediate steps within the new gate boundaries?
  4. What happens when different steps within the same group specify different concurrency limits (such as step A in group G having a limit of 1, while step B in group G has a limit of 2)? Would step A need to wait until B is done if B starts first? Conversely would step B be able to proceed even if A is already running? Is the behavior influenced by those steps living in the same or different builds/pipelines?

Thanks!

2

Hey @kgillette

These are great questions! I’ll try and answer each below:

  1. That’s correct.
  2. Correct, the group would be blocked unless you had a concurrency of 2
  3. The “gate” respects these steps and adds them within the boundaries.

For your last question, I’m actually not sure yet! I’m looking into it a bit more to try and find a clear answer for you, and I’ll be sure to update this thread when I have more information :slight_smile:

3

Hi @kgillette,

I just checked the 4th question and it is a very interesting one.

If Step A (with concurrency limit 1) starts first, then Step B (with concurrency limit 2) will also enter into the concurrency group and start running. This is because, when a job is created and ready to be scheduled, it gets into the concurrency waitlist if there is already any step in the waitlist. Otherwise, it checks the number of jobs currently running in the concurrency group. If it is under its concurrency limit (in this case, it is), then it enters the concurrency group. Otherwise, it waits.

If Step B starts first, then Step A would wait as its concurrency_limit is 1 and there is already one job (step B) running within the concurrency group.

Hope this clarifies!

Best,
Nithya

4

Excellent, thank you both!