Forked from https://github.com/promiseofcake/circleci-workflow-queue, which was forked from https://github.com/eddiewebb/circleci-queue.
Promiseofcake's fork migrated to use CircleCI's v2 API, which has much more complete workflow/job information than v1. In doing so it simplified the orb down a lot so it only blocks on entire workflows.
This fork adds the original functionality to queue by job back in, but using the v2 API which lets us fetch jobs that are both running and scheduled to run in the future. The behavior differs from the original queue orb in that while the original only ensure that jobs do not run in parallel, here we can ensure jobs will queue in order of their creation, and thus run sequentially. This is probably more in line with how most people expect the queue orb to work. We can now block execution of a job/workflow at specific "gates" along a workflow, even doing so multiple times if needed, guaranteeing that all instances of that job run in order.
For example, for a workflow that looks like:
- Test (wildy variable in runtime)
- Block execution, wait for earlier staging deploys to finish Deploy to staging environment
- Hold for manual approval
- Block execution, wait for earlier prod deploys to finish Deploy to production environment
Job 2 will only block on earlier instances of job 2, even scheduled ones that aren't actually running yet. Independently, job 4 will also do so for earlier instances of job 4. Here, if multiple pushes are maded to a branch in succession, we can have the latest changes deployed to staging environment automatically (guaranteeing that old changes aren't deployed over newer ones e.g. if their tests happened to run slower), and same for production, even after waiting for manual approvals that could come out of order. This is nice because latest changes can still go to staging, even if production is being blocked purposely on an earlier change.
Note that we do not paginate on the circleci endpoints, so jobs will only block on other jobs running in the last 20 pipelines or so.
In order to use this orb you will need to export a CIRCLECI_API_TOKEN secret added to a context of your choosing. It will authentcation against the CircleCI API to check on workflow status. (see: https://circleci.com/docs/api/v2/index.html#section/Authentication)
CircleCI Orb Registry Page - The official registry page of this orb for all versions, executors, commands, and jobs described.
CircleCI Orb Docs - Docs for using, creating, and publishing CircleCI Orbs.
We welcome issues to and pull requests against this repository!
- Merge pull requests with desired changes to the main branch.
- For the best experience, squash-and-merge and use Conventional Commit Messages.
- Find the current version of the orb.
- You can run
circleci orb info tkoft/job-queue | grep "Latest"to see the current version.
- You can run
- Create a new Release on GitHub.
- Click "Choose a tag" and create a new semantically versioned tag. (ex: v1.0.0)
- We will have an opportunity to change this before we publish if needed after the next step.
- Click "Choose a tag" and create a new semantically versioned tag. (ex: v1.0.0)
- Click "+ Auto-generate release notes".
- This will create a summary of all of the merged pull requests since the previous release.
- If you have used Conventional Commit Messages it will be easy to determine what types of changes were made, allowing you to ensure the correct version tag is being published.
- Now ensure the version tag selected is semantically accurate based on the changes included.
- Click "Publish Release".
- This will push a new tag and trigger your publishing pipeline on CircleCI.