I have a similar use case as mentioned in this old topic.
We have run into a situation where two PRs are merged within a few seconds of each other and due to the dynamic nature of CircleCI build environments sometimes the one merged second finishes first and triggers a deployment. Then the first one completes and triggers another deployment. Our deployment software limits one concurrent deployment job, but in this case, the “older” commit gets deployed over the “newer”.
I would like to be able to enforce certain jobs run in order. GitHub Actions has a concurrency key that provides more granularity than the “Auto-cancel redundant workflows” option in CircleCI.
I’m trying to get a pipeline working that deploys a docker container to our kubernetes cluster. If 2 PRs merge close together, one build will fail because its deployment gets interrupted by the other.
I need a way to prevent newer builds from running until the current one is finished. Ideally, all builds queued up during the current build would be grouped up and ran together once the current build ends.
Note that there’s a feature “under review” that would help with this – definitely consider voting for it if you think it would be good for your use case.
Also, I believe it’s possible to limit concurrency using self-hosted executors by only having one deployment / replica, however, that would affect all branches / projects using that executor, not just a single branch / project combination.