How to limit concurrent workflow runs

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.

2 Likes

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.

1 Like

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.

3 Likes

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.

1 Like

Any update on this request?

2 Likes

This is a crucial feature, we need to be able to limit the number of parallel runs for certain workflows.

1 Like

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 …

Can try this script https://github.com/marketplace/actions/wait-for-check

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.

1 Like

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

c.f. https://docs.gitlab.com/ee/ci/yaml/#resource_group

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:

  • concurrent deployments if you merge/commit fast enough (and your deploy time takes a few minutes)
  • out of order deployments since in my experience workflows for 2 commits on the same branch are executed in a random order (i.e. an older commit can end up “winning” the deploy over the most recent commit).
1 Like