|
| 1 | +{% ifversion actions-nga %} |
| 2 | + |
| 3 | +This means that there can be at most one running job or workflow in a concurrency group at any time. When a concurrent job or workflow is queued, if another job or workflow using the same concurrency group in the repository is in progress, the queued job or workflow will be `pending`. By default, any existing `pending` job or workflow in the same concurrency group will be canceled and the new queued job or workflow will take its place. |
| 4 | + |
| 5 | +{% else %} |
| 6 | + |
1 | 7 | This means that there can be at most one running and one pending job in a concurrency group at any time. When a concurrent job or workflow is queued, if another job or workflow using the same concurrency group in the repository is in progress, the queued job or workflow will be `pending`. Any existing `pending` job or workflow in the same concurrency group, if it exists, will be canceled and the new queued job or workflow will take its place. |
2 | 8 |
|
| 9 | +{% endif %} |
| 10 | + |
3 | 11 | To also cancel any currently running job or workflow in the same concurrency group, specify `cancel-in-progress: true`. To conditionally cancel currently running jobs or workflows in the same concurrency group, you can specify `cancel-in-progress` as an expression with any of the allowed expression contexts. |
4 | 12 |
|
| 13 | +{% ifversion actions-nga %} |
| 14 | + |
| 15 | +To allow more than one `pending` job or workflow run to wait in the same concurrency group, use the optional `queue` property. The `queue` property accepts the following values: |
| 16 | + |
| 17 | +* `single` (default): At most one job or workflow run can be `pending` in the concurrency group. When a new job or workflow run is queued, any existing `pending` job or workflow run in the same group is canceled and replaced. |
| 18 | +* `max`: Up to 100 jobs or workflow runs can be `pending` in the concurrency group. When the queue is full, any additional jobs or workflow runs are canceled. |
| 19 | + |
| 20 | +The combination of `queue: max` and `cancel-in-progress: true` is not allowed and will result in a workflow validation error. |
| 21 | + |
| 22 | +{% endif %} |
| 23 | + |
5 | 24 | > [!NOTE] |
6 | 25 | > * The concurrency group name is case insensitive. For example, `prod` and `Prod` will be treated as the same concurrency group. |
7 | | -> * Ordering is not guaranteed for jobs or workflow runs using concurrency groups. Jobs or workflow runs in the same concurrency group are handled in an arbitrary order. |
| 26 | +> * Jobs or workflow runs in the same concurrency group are processed in first-in-first-out (FIFO) order according to the time each one started waiting on the concurrency group, not the time each workflow was dispatched. Since the actual start time of a job or run may vary, ordering is not guaranteed. |
8 | 27 |
|
9 | 28 | ### Example: Using concurrency and the default behavior |
10 | 29 |
|
@@ -81,6 +100,33 @@ concurrency: |
81 | 100 |
|
82 | 101 | {% endraw %} |
83 | 102 |
|
| 103 | +{% ifversion actions-nga %} |
| 104 | + |
| 105 | +### Example: Queueing multiple pending runs |
| 106 | + |
| 107 | +By default, only one job or workflow run can be `pending` in a concurrency group at a time. To allow multiple runs to queue instead of being canceled, set `queue: max`. With `queue: max`, up to 100 jobs or workflow runs can wait in the concurrency group; once the queue is full, any additional runs are canceled. |
| 108 | + |
| 109 | +For example, the following workflow queues deployments to the `production` environment, processing them one at a time in order based on when each run started waiting on the concurrency group: |
| 110 | + |
| 111 | +{% raw %} |
| 112 | + |
| 113 | +```yaml |
| 114 | +on: |
| 115 | + push: |
| 116 | + branches: |
| 117 | + - main |
| 118 | +
|
| 119 | +concurrency: |
| 120 | + group: production-deploy |
| 121 | + queue: max |
| 122 | +``` |
| 123 | + |
| 124 | +{% endraw %} |
| 125 | + |
| 126 | +Note that `queue: max` cannot be combined with `cancel-in-progress: true`, because the two options describe conflicting behaviors for handling in-progress runs. |
| 127 | + |
| 128 | +{% endif %} |
| 129 | + |
84 | 130 | ### Example: Using concurrency to cancel any in-progress job or run |
85 | 131 |
|
86 | 132 | To use concurrency to cancel any in-progress job or run in {% data variables.product.prodname_actions %}, you can use the `concurrency` key with the `cancel-in-progress` option set to `true`: |
|
0 commit comments