From a967e806462073b8018b2c4d6c23e72d9ce78114 Mon Sep 17 00:00:00 2001 From: Tom Watt Date: Wed, 15 May 2024 14:15:41 +0100 Subject: [PATCH 1/2] docs: highlight block and input steps cannot be used within concurrency gates --- pages/pipelines/controlling_concurrency.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/pages/pipelines/controlling_concurrency.md b/pages/pipelines/controlling_concurrency.md index 357acac2a8..5ce1d4041f 100644 --- a/pages/pipelines/controlling_concurrency.md +++ b/pages/pipelines/controlling_concurrency.md @@ -45,7 +45,9 @@ Concurrency groups guarantee that jobs will be run in the order that they were c ## Concurrency and parallelism Sometimes you need strict concurrency while also having jobs that would benefit from parallelism. -In these situations, you can use *concurrency gates* to control which jobs run in parallel and which jobs run one at a time. Concurrency gates come in pairs, so when you open a gate, you have to close it. You can't use input or block steps inside concurrency gates. +In these situations, you can use *concurrency gates* to control which jobs run in parallel and which jobs run one at a time. Concurrency gates come in pairs, so when you open a gate, you have to close it. + +> 🚧 [block](/docs/pipelines/block-step) and [input](/docs/pipelines/input-step) steps cannot be used inside concurrency gates. In the following setup, only one build at a time can *enter the concurrency gate*, but within that gate up to three e2e tests can run in parallel, subject to Agent availability. Putting the `stage-deploy` section in the gate as well ensures that every time there is a deployment made to the staging environment, the e2e tests are carried out on that deployment: From 85c0e5403e9d7bb5360abd99c5d1ec9dd02ebd85 Mon Sep 17 00:00:00 2001 From: Giles Gaskell Date: Fri, 17 May 2024 16:51:30 +1000 Subject: [PATCH 2/2] Tweak wording of concurrency messages. --- pages/pipelines/controlling_concurrency.md | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/pages/pipelines/controlling_concurrency.md b/pages/pipelines/controlling_concurrency.md index bacd5c5071..5a3c9a4eb2 100644 --- a/pages/pipelines/controlling_concurrency.md +++ b/pages/pipelines/controlling_concurrency.md @@ -45,16 +45,17 @@ Concurrency groups guarantee that jobs will be run in the order that they were c > 🚧 Troubleshooting and using `concurrency_group` with `block` / `input` steps > When a build is blocked by a concurrency group, you can check which jobs are in the queue and their state using the [`getConcurrency` GraphQL query](/docs/apis/graphql/cookbooks/jobs#get-all-jobs-in-a-particular-concurrency-group). >

-> Be aware that both the [`block`](/docs/pipelines/block-step) and [`input`](/docs/pipelines/input-step) steps cause these steps to be uploaded and scheduled at the same time, which breaks concurrency groups. These two steps block jobs being added to the concurrency group, but do not affect the jobs' ordering once unblocked. The concurrency group won't be added to the queue until the `block` or `input` step is unblocked, and once it is, the timestamp will be from the pipeline upload step. +> Be aware that both the [`block`](/docs/pipelines/block-step) and [`input`](/docs/pipelines/input-step) steps cause these steps to be uploaded and scheduled at the same time, which breaks concurrency groups. These two steps prevent jobs being added to the concurrency group, although these steps do not affect the jobs' ordering once they are allowed to continue. The concurrency group won't be added to the queue until the `block` or `input` step is allowed to continue, and once this happens, the timestamp will be from the pipeline upload step. ## Concurrency and parallelism Sometimes you need strict concurrency while also having jobs that would benefit from parallelism. -In these situations, you can use *concurrency gates* to control which jobs run in parallel and which jobs run one at a time. Concurrency gates come in pairs, so when you open a gate, you have to close it. +In these situations, you can use _concurrency gates_ to control which jobs run in parallel and which jobs run one at a time. Concurrency gates come in pairs, so when you open a gate, you have to close it. -> 🚧 [block](/docs/pipelines/block-step) and [input](/docs/pipelines/input-step) steps cannot be used inside concurrency gates. +> 🚧 +> Since [`block`](/docs/pipelines/block-step) and [`input`](/docs/pipelines/input-step) steps [prevent jobs being added to concurrency groups](#troubleshooting-and-using-concurrency-group-with-block-slash-input-steps), you cannot use these two steps inside concurrency gates. -In the following setup, only one build at a time can *enter the concurrency gate*, but within that gate up to three e2e tests can run in parallel, subject to Agent availability. Putting the `stage-deploy` section in the gate as well ensures that every time there is a deployment made to the staging environment, the e2e tests are carried out on that deployment: +In the following setup, only one build at a time can _enter the concurrency gate_, but within that gate up to three e2e tests can run in parallel, subject to Agent availability. Putting the `stage-deploy` section in the gate as well ensures that every time there is a deployment made to the staging environment, the e2e tests are carried out on that deployment: ```yaml steps: