Concurrency: cancel-pending parameter?

Current implementation of concurrency cancels all the pending workflow instances of the same concurrency group when a new workflow (of the same concurrency group) is started.

Is it possible to keep them in pending state and let them run one by one? It is usefull if you want to serialize deployments but don’t want to have some of them skipped because of this.

12 Likes

Same issue for us, I commented with our use case here: How to limit concurrent workflow runs - #48 by jasperroel

4 Likes

We have the same issue. We need our GitHub workflows to run sequentially but the default behaviour of the concurrency parameter is to cancel the previous pending workflows.

Same here, seems like Pending only works with one workflow and cancel the others…

This is also essential to us.

I actually thought that concurrency would allow me to leave all jobs pending and not cancel, and I planned some other features around this. Fortunately, I read the workflow docs more carefully and realized this is not possible. This blocks some stuff I wanted to roll out & is a big problem.

FWIW, although I really think the implementation of cancel-pending really ought to preserve the order of the jobs/workflows in queue, for our specific use-case this isn’t necessary. For example, if all the subjects just checked if they could acquire the lock, and waited if they couldn’t, and just woke up after $RANDOM secs & checked again, that would work.

I also run into that problem.

For my use case, i want to deploy gh-pages in a job, but it is not possible to write at the same time in the gh-pages branch. For that i want to queue all jobs, so all docs that i want to deploy to the branch are kept.

1 Like

I also run into this problem. Looking at the number of responses here, this is an issue for quite some folks out there.

Created this discussion if you want to :+1: it. https://github.com/github/feedback/discussions/5435