Concurrency Cancel Pending

[niall-shaw]

Select Topic Area

Product Feedback

Body

Follow-up on https://github.com/orgs/community/discussions/5435

Numerous member of the community have been asking for this feature for years now, however we haven't heard back from a Github employee in 2 years.
I am creating a new issue in hope to attract attention to this, as the referenced discussion is incorrectly closed as answered.

Any previously pending job or workflow in the concurrency group will be canceled.
Any chance we can make this configurable? The expectation for concurrency is to ensure jobs are run in order and not concurrent. Cancelling jobs seems to defeat the purpose of ensuring order. I would envision a cancel-pending: true if we wanted this or at least allow us to set it to false if we don't want it.
https://docs.github.com/en/actions/reference/workflow-syntax-for-github-actions#concurrency

[sergio-toro]

Yes, this will be an amazing feature to add! For monorepos especially useful!

[gustaff-weldon]

+1.

Lack of cancel-pending: false is an only blocker keeping us from using concurrency. We want all deployment PRs to be queued, not cancelled as they might deploy different things from our monorepo.
They should go in order. Currently we rely on https://github.com/softprops/turnstyle but is not being maintained...

[koppor]

I agree to that property. In addition, there should be a cancelling (and re-queueing) possible if new commits are put into the branch. Otherwise, commits will get lost:

[harpener]

Hi guys, our use case is that we need a passive queue mechanism, two levels of concurrency instead of just one. Our workflow for status checks should cancel pending tasks from the same group 1 (pull request), but keep pending tasks from a different group 2 (repository). Essentially, the workflow should never run in parallel, but should always be queued if it comes from a different pull request. Not being able to specify more groups would be fine as long as we can at least disable cancelling pending tasks at all. This is what we had in Jenkins CI. I find it hard to believe that this is such a rare use case unsolved for years.

[mr-short]

Considering they have merge queues on PRs (for public or Enterprise users 👀) they probably won't implement this

https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/configuring-pull-request-merges/managing-a-merge-queue

[Felixoid]

how it would help to address a topic?..

[mr-short]

@Felixoid Instead of the commits getting stuck in a CICD queue after merge, it would get stuck in a merge queue before it hits CICD

[Felixoid]

It's completely orthogonal solution.

Issues aren't only with commits in the main branches. For us, the launch of workflows with concurrency is triggered by PRs with a label. And merge queue wouldn't help here at all.

Another example is releases. Our release process requires blocking wait, and it's solved on the completely another level, because actions don't bother to fix the issue. A pending queue would fix it too.

edited: typos

[andyjhull]

Agreed, this wouldn't address our needs either.

[kota65535]

Any previously pending job or workflow in the concurrency group will be canceled.

We have a Slack integration that triggers our workflow but sometimes they are cancelled because of this behavior.
The current behavior is not intuitive and does not cover most use cases. Please simply add a new job to the queue without canceling it.

[koppor]

The action skip-duplicate-actions could be a solution. However, the PR for support of merge_group (fkirc/skip-duplicate-actions#329) still needs some work. Maybe someone here can help?

[andyjhull]

I don't think this applies at least to our needs. There are no duplicate jobs in our scenario, we just need all of them to run in the order they were queued without getting cancelled.

I'd also prefer a built-in solution from Github rather than a workaround.

[koppor]

The name of the action is misleading. When scrolling down the README.md, one finds following:

Cancel outdated workflow runs

Typically, workflows should only run for the most recent commit. Therefore, when you push changes to a branch, skip-duplicate-actions can be configured to cancel any previous workflow runs that run against outdated commits.

I agree that a solution by GitHub is preferable. I just wanted to point out that there is a workaround for merge queues with enabled build concurrency.

[acovaci]

Yet another 👍 from me, very similar problem: We need a proper mutex behaviour in order to ensure sequential runs. It's important so that we ensure consistency of the concurrent merges over time, but also so that we don't lose traceability of what merge caused what action to change status.

In addition to this, actions don't only run on merges, they can be scheduled. This issue also arises in that case, scheduled runs end up cancelling in progress merge actions, or vice versa.

[koppor]

We need a proper mutex behaviour in order to ensure sequential runs.

This is easy: Set the queue size to 1.

we ensure consistency of the concurrent merges over time, but also so that we don't lose traceability of what merge caused what action to change status.

Even with concurrency, merge queues allow that.

Let me explain in short.

Assume, you have concurrency 5.

Assume, PRs 1, 2, 3, 4 are build concurrently.

Then following builds are made:

Build / PR	1	2	3	4
A	x
B	x	x
C	x	x	x
D	x	x	x	x

That means:

• PR1 gets main merged
• PR2 gets main and PR1 merged
• PR3 gets main and PR1 and PR2 merged
• PR4 gets main and PR2 and PR3 merged

If B fails, following builds are made:

Build / PR	1	2	3	4
A	x
C	x		x
D	x		x	x

If all succeed, three commits are made:

• 1st commit: merge PR1
• 2nd commit: merge PR3
• 3rd commit: merge PR4

I think, this perfectly satisfies your requirement. -- And also matches the effect of a queue - even though the implementation is different (because parallel builds are done).

Detailed text: https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/configuring-pull-request-merges/managing-a-merge-queue#triggering-merge-group-checks-with-github-actions

[acovaci]

@koppor The key is in the comment:

actions don't only run on merges

So no, merge queues don't apply here

[koppor]

I think, one needs to think thoroughly about concurrency and workflows.

My current bet is that following configuration works:

concurrency:
  group: "${{ github.workflow }}-${{ github.head_ref || github.ref }}"
  cancel-in-progress: true

Reasons:

1. pull-requests define github.head_ref
2. merge queue builds define github.ref
3. merge queue builds work on a different branch then the source or target branch

The property of the merge queue ensures that the build are run as if they were executed one after another. (Even with size of parallel builds > 1)

However, if one uses external services and some ordering is required there, one needs to set the size of the merge builds to 1.

[Felixoid]

In the end, please consider that not everything is launched from the branches after the merge. Especially in the default branch.

As stated:

Folks, let's get the terminology right. It does not seem an issue to some of you exactly because you're interpreting actions to only run on merges, which is absolutely not the case.
Actions can be scheduled, triggered manually, etc.

I'd extend it by reviewing pull requests, tagging, and releasing. But for the full list of events, please refer to https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows

Thank you.

[dgillman]

Yes please! This is so aggravating. Concurrency control should not kill off running jobs!

De-duplication != concurrency control

Concurrency control is frequently a means to gatekeep a resource that can only handle one transaction/modification at a time. The choice to randomly kill of queued jobs in the same concurrency group violates the Principle of Least Surprise.

Please fix this! It is clear that numerous customers have been afflicted by this implementation for years.

[koppor]

I think, the feature request needs to be detailed with an example. (No killing is available, killing older runs is possible, parallel builds of different pull request and then merge is possible)

In my view, merge queues with proper concurrency-group configuration allow the desired behavior.

In case a scenario is not hit, a work-around could be crafted with Skip Duplicate Actions Cancel Workflow Action?

[dgillman]

Easy example:

1. I maintain seven environments that run releases of the same code base.
2. I deploy to these environments from GitHub Actions.
3. I execute deploys when the repo is tagged with a tag matching a specific semver pattern
4. Multiple environments receive the release at the same time in some cases
5. Since the deploy involves a newly tagged repo, the first thing that the deploy workflow needs to do is to build and label a deployable asset, and upload it to a registry.
6. Building, labelling and uploading for the same artifact may cause processes to clobber each other, so the concurrency on this project needs to limit execution to a single instance at a time.

Actual concurrency control would allow me to say precisely "only N instances of the build, label, upload step can run at a time". It would not only function on merges.

This is not what GitHub has implemented. It has implemented "only 1 instance can run... all the others will be killed off". This adds an unexpected "winner take all" side effect to something labelled "concurrency control". It violates the expectations of GitHub customers, as evidenced by years of this issue coming up, with hundreds of upvotes.

This feature request, then is:

1. Please implement concurrency control that does not kill off any jobs.

For my money, the mechanism is entirely up to the implementer. Though the proposal the OP highlighted seems like a fairly helpful way of approaching the issue. It suggests addition of a cancel-pending boolean flag which defaults to true. This is a seemingly low-risk implementation because it leaves the current functionality, while adding an option for the exceptional case (?) where people needing concurrency control and only concurrency control can use the feature called "concurrency control" without having their jobs killed off.

[hitsthings]

Merge queues don't solve this. Merging and actions are two different things. Not every build is a merge. For example I run tests against a production resource at regular intervals. The tests cannot be run from multiple sources simultaneously. They need to be run one-by-one.
The functional tests might also run because I merged code. I want both run, but not be cancelled cancelled ever.

Similarly, I run against a singular dev resource whenever you push to a dev branch. These tests also can only be run serially against the singular resource, but you'd never want any cancelled - they are running on completely different branches and testing completely different code. I never want to cancel a pending job in this group. Just line them up.

[acovaci]

Merging and actions are two different things

👍🏻

Folks, let's get the terminology right. It does not seem an issue to some of you exactly because you're interpreting actions to only run on merges, which is absolutely not the case.

Actions can be scheduled, triggered manually, etc.