Learn · Concurrency

Concurrency groups

Some work must not overlap with itself. Two deploys to the same environment, two migrations against the same database, two publishes of the same package.

steps:
  - key: deploy
    command: make deploy
    branches: "main"
    concurrency: 1
    concurrency_group: "production-deploy"

concurrency_group names a queue that spans your whole organisation. concurrency says how many jobs in that group may run at once. Jobs beyond the limit wait their turn.

Both fields are required. concurrency: 1 on its own does nothing — without a group there is nothing to be concurrent with. This is the most common mistake with this feature, and it fails silently: the pipeline is valid, the deploys are simply not serialised, and you find out during an incident.

The group is a string you choose, and it is global. Two different pipelines using production-deploy are serialised against each other, which is usually exactly what you want — the environment does not care which pipeline is deploying to it.

Limits above one are legitimate:

    concurrency: 3
    concurrency_group: "integration-suite/shared-database"

That says at most three jobs may touch the shared database at once, whatever build they belong to.