Is there any way to prevent the same workflow from running more than once at the same time?
For example, I have a workflow to deploy to our dev environment on any push to master. If multiple pull requests are merged one after the other, the workflow will run multiple times which could cause a race condition where the most recent commit isn’t the one that finally gets deployed.
There is currently no way to force a workflow to have only one run at a time. As we look forward to more formal support for continuous delivery scenarios this is somthing we will look to address.
I would say this is quite a critical feature. One that would prevent us from migrating from Travis to GH Actions. Our use case: Each build starts the integration tests. The integration tests deal with one data store, where they clean it completely and then start running tests on it. If more than one instance of the integration tests run in parallel, it would mean that tests will be modifying that one data store in parallel, which would lead to race conditions and eventually both fail.
I have just run into this same problem. Are there any updates Chris?
Thank you!
@chrispat Any updates on this? I can’t think of a CD scenario, where parallel workflow executions are acceptable.
I think is a bit disingenuous to mark this as solved when you are just considering to work on it at the moment.
Just want to say this would be great to have and save us from having to orchestrate this ourselves with external systems.
@chrispat is this an issue that could be put on the github roadmap? That way the issue can actually be followed.
I think that I may have noticed this happen which caused a failing test to “pass” unexpectedly. I had not seen this discussion, but I explained the circumstances here.
Some timeline would be nice for this feature. Like, can we expect this to come in the next ~6 months or something? It’s one of those crucial things that might block us from moving to GitHub Actions from other CI/CD systems.
Check out Turnstyle. It does the job.
I published an Action that prevents duplicate workflow-runs: https://github.com/fkirc/skip-duplicate-actions
You may check it out if this is still an issue.
This is critical feature, my automation testing stability depends from it!
Same here, really need this.
Using a 3rd party action adds complexity to the pipeline (additional step that can fail, can have bugs, more configuration), and requires a secret token to be exposed to 3rd party code. However, it’s really cool that you made a stab at solving this problem!
I’d love to get this resolved out of the box by GitHub.
In my understanding, GitHub is waiting for third-party actions before they are adding native features.
In fact, even for this small action there have been a surprisingly large number of “non-trivial” issues that were only resolved because of community-bugfixes.
But anyways, GitHub adopted “skip-duplicate-actions” for their own documentation, so it is reasonable to assume that they might implement it natively.
With respect to security, I would like to have a default-token for third-party actions such that (1.) only the same repo can be queried and (2.) all non-GitHub-API requests are blocked.
This would reduce boilerplate code because we wouldn’t need to pass tokens all the time, and it would also increase the security of third party actions.
Right now, the only option seems to be a manual code review + commithash-locking, which is doable for small Actions like mine, but very tedious for large Actions.
@chrispat, developer experience suffers because of this problem. The “checks” view in the PR is cluttered with duplicated information, and I need scroll to review all the checks. We use build matrix, so 10 jobs become 20 jobs, see example: https://github.com/mockito/mockito/pull/2098
PS. I love GH Actions - it is a great product. Thanks!
I wrote a “living specification” about how these issues might be solved once and for all: https://github.com/fkirc/skip-duplicate-actions/issues/59
It is not entirely trivial, but I think that it is doable with enough care for details and iterations.