Avoid concurrent workflows on main branch


We have a build and release workflow running on our main branch. It checks out the code builds it, deploys it to our staging environment and then runs tests against the staging environment.
Since we only have one staging env we cannot have a later workflow start before we are done with deploy and testing.

I’ve seen a orbs like eddiewebb/queue that allows to pause a workflow until the previous workflow is done.
But if multiple people merges to our main branch while deploy+test is running the last person to merge will have to wait a long time for his change to hit staging.

So is there a way to cancel a paused workflow if there are new workflows starting, but not cancel the workflow currently deploying and testing?

Best regards,

Hi @mtandrup,

You mention “paused workflows”. Does this mean you’re using approval jobs?

If so, you could use the same logic as that used in this workaround, but only match workflows in an on_hold state.

Let me know if this helps.

Hi @yannCI

We do use hold: approval step. But when I mentioned pausing I was referring to something like what GitHub - eddiewebb/circleci-queue: CircleCI orb to block/queue jobs to enforce max concurrency limits does.

In your example you end up cancelling the older running build, right?

What I would like to accomplish is:

  1. Dev merges PR to master
  2. Trigger pipeline to build, test and deploy to our environments.
  3. While the build from step 2 is building, any dev merges PR to master should not start a new build.
  4. Immediately after the build from step 2 is done, start a new build to pick up all the commits happening in step 3.

And continue that process until there are no more commits coming in.