Troubleshooting concurrency groups #2503
Conversation
When a build is stuck because of a concurrency group, it is hard to see which jobs are in the queue. We have a GraphQL query that is very useful in these situations, and it lists all jobs in the queue of a concurrency group and its state. We eventually have something in the UI (we have it already but the performance it's not very good)
pzeballos
requested review from
mbelton-buildkite,
MelissaKaulfuss and
meiqimichelle
as code owners
github-actions
bot
added
the
pipelines
|
Preview URL: https://2503--bk-docs-preview.netlify.app |
| @@ -43,6 +43,9 @@ For example, if you have two pipelines that each deploy to a different target bu | |||
|
|
|||
| Concurrency groups guarantee that jobs will be run in the order that they were created in. Jobs inherit the creation time of their parent. Parents of jobs can be either a build or a pipeline upload job. As pipeline uploads add more jobs to the build after it has started, the jobs that they add will inherit the creation time of the pipeline upload rather than the build. | |||
|
|
|||
| >📘 Troubleshooting | |||
| > When a build is blocked by a concurrency group, you can run this [GraphQL query](/docs/apis/graphql/cookbooks/jobs#get-all-jobs-in-a-particular-concurrency-group) that will list all the jobs that are in the queue for that particular concurrency group. | |||
There was a problem hiding this comment.
I think this is a bit clearer:
| > When a build is blocked by a concurrency group, you can run this [GraphQL query](/docs/apis/graphql/cookbooks/jobs#get-all-jobs-in-a-particular-concurrency-group) that will list all the jobs that are in the queue for that particular concurrency group. | |
| > When a build is blocked by a concurrency group, you can check which jobs are in the queue and their state using this [GraphQL query](/docs/apis/graphql/cookbooks/jobs#get-all-jobs-in-a-particular-concurrency-group). |
There was a problem hiding this comment.
I've already committed this suggestion @pzeballos ; I'm assuming this wording revision is OK from your perspective?
Co-authored-by: Michael Belton <[email protected]>
There was a problem hiding this comment.
Hi @pzeballos , just want you to confirm if this word modification (italicised) is correct...
Be aware that both the
blockandinputsteps cause these steps to be uploaded and scheduled at the same time, which breaks concurrency groups.
By "these", I'm referring to either the block or input steps themselves.
Is this correct?
That is correct @gilesgas ! |
When a build is stuck because of a concurrency group, it is hard to see which jobs are in the queue. We have a GraphQL query that is very useful in these situations, and it lists all jobs in the queue of a concurrency group and its state.
We eventually have something in the UI (we have it already, but the performance is not very good)
I wasn't sure where to add this note, so I put it as an info section