See post referencing Turnstyle.
I added the action and it blocked until the already running action completed.
Thanks @softprops . I’d consider this featured request solved.
Thanks Github for making Actions flexible enough to allow the community to help make Actions feature rich.
If actions happen fast, there are a lot of room for two actions getting green light and starting at the same time.
Quite easy to reproduce with repository dispatch event and curl. Just do two at the same time, and you’ll get two running actions at the same time. Race condition, because there is no real lock acquired by the action, only checking if no actions run at current point in time.
Thank you @softprops for Turnstyle.
Unfortunately with one of my repositories I have many jobs (>40) and despite setting the poll-interval-seconds high I do hit GitHub API limits. I think that there is still value in a GitHub-official solution to this problem.
edit: I misinterpreted the in progress view of my deployment actions. Turnstyle does in fact allow my staging and production deploys to run in parallel.
I think Turnstyle is a clever solution but only for certain deployment setups. It’s not general purpose. Our deployment workflow has parallel jobs for staging and production, but those are considered separate runs and Turnstyle serializes them.
We need either a workflow-level concurrency limit, a mutex primitive, or best of all a queue primitive (to avoid wasted minutes).
Would also like this feature. With the Turnstyle solution, it can eat a lot of minutes waiting for a deployment which can take ~10mins to deploy especially if we have a backlog of >10 commits staged for deployment.
Any update on this request?
This is a crucial feature, we need to be able to limit the number of parallel runs for certain workflows.
In the meantime I found https://github.com/byu-oit/github-action-disallow-concurrent-runs. Hope this helps. But we definitely need such a feature …
While these links are helpful for anyone with very quick / few workflows in a queue, those with longer workflow runs and/or large queues will quickly eat into workflow minutes unnecessarily.
I think what we’re aiming for here, is a natively supported configuration to save those minutes otherwise spent polling.
For some use cases the https://github.com/styfle/cancel-workflow-action might be helpful to save on build minutes and avoiding race conditions.
I want to use feature like GitLab CI’s resource_group on GitHub Actions
I also want the native support for limiting concurrent running.
What I want is, when triggered, not only cancelling already running, but also just dequeuing not started ones if present.
Ensuring order of queueing is also important thing around this topic.
Ye this would helo me a lot too
I’ll add my +100 to this. I just don’t understand how GitHub presents Actions as a CI/CD tool when you can’t ensure that a branch can be reliably deployed to a production server, since you will end up with:
we achieved this using actions-mutex.
However, this is rather a poor workaround, because one has to pay for the Action minutes while waiting for the mutex to unlock. This is especially costly when using macos mintues.
I also would like this feature. As it was pointed out, the existing workarounds would just cause wasted minutes. Ability to limit the concurrent workflow runs or a proper queuing mechanism would help a lot.
Hitting the same issue here. Any workflow that commit changes needs this. Currently we have to retry rebase+push over and over again until it goes through.
The feature should be configurable per-branch basis. Master would run in series, rest of the branches in parallel. In optimal case it would also be configurable in a way that it would always build just the latest commit and skip the intermediate ones. So if I’m building commit 1, and in the mean time commits 2 and 3 appears, it would skip commit 2 and directly start building commit 3 after commit 1 build finishes.
Adding another +1 for this. Limiting concurrency is a feature I used in Travis, in a prior job. Would be useful to avoid edge-casey confusion in a current build using github actions. 
