Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SUP-2217: highlight block and input steps cannot be used within concurrency gates #2799

Open
wants to merge 3 commits into
base: main
Choose a base branch
from
Open

SUP-2217: highlight block and input steps cannot be used within concurrency gates #2799

Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
a967e80
docs: highlight block and input steps cannot be used within concurren…
tomowatt May 15, 2024
394b051
Merge remote-tracking branch 'origin/main' into SUP-2217
gilesgas May 17, 2024
85c0e54
Tweak wording of concurrency messages.
gilesgas May 17, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
9 changes: 6 additions & 3 deletions pages/pipelines/controlling_concurrency.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -45,14 +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).
> <p>
> 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. 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.

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:
> 🚧
> 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:

```yaml
steps:
Expand Down
Loading