CircleCI Orb to limit workflow concurrency.
Why? Some jobs (typically deployments) need to run sequentially and not parallel, but also run to completion. So CircleCI's native auto-cancel
is not quite the right fit.
See https://github.com/ekulabuhov/circleci-challenge as an example using blue/green cloud foundry deployments.
This adds concurrency limits by ensuring any jobs with this step will only continue once no previous builds are running. It supports a single argument of how many minutes to wait before aborting itself and it requires a single Environment Variable CIRCLECI_API_KEY
- which can be created in account settings. EK: It needs a personal API key because the script mixes v1 and v2 calls. Unfortunately, v2 calls don't support project API keys.
Suppose we have a workflow take takes a little while to run. Normally the build (#18) will run immediately, with no queuing.
Someone else on the team makes another commit, since the first build (#18) is still running, it will queue build #19.
It's late afternoon, everyone is pushing their commits in to ensure they are good before they leave for the day. Build #20 also queues.
Meanwhile, build #19 is now allowed to move forward since build #18 finished.
Oh No! Since 1 minute
is abnormally long for things to be queued, build #20 aborts itself, letting build #19 finish uninterrupted.
See https://circleci.com/orbs/registry/orb/ekulabuhov/queue#usage-examples for current examples
Queueing is not supported on forked repos. If a queue from a fork happens the queue will immediately exit and the next step of the job will begin.
circleci config pack src/ > packed.yml circleci orb publish packed.yml ekulabuhov/circle-queue@dev:8 circleci orb publish promote ekulabuhov/circle-queue@dev:8 patch