GitHub Community
Replies: 62 comments 21 replies
-
|
(Seems like this discussion is missing a few labels, but I'm not sure what to do to add them.) |
Beta Was this translation helpful? Give feedback.
-
|
See also: actions/runner#1523, actions/runner#2227 (folks from GH saying not their problem), https://github.com/orgs/community/discussions/5435 (folks from GH saying they won't implement, a year ago), https://github.com/orgs/community/discussions/33142, https://github.com/orgs/community/discussions/12835, https://github.com/orgs/community/discussions/33948, https://github.com/orgs/community/discussions/32376. Related: https://github.com/orgs/community/discussions/31040, https://github.com/orgs/community/discussions/31544. Plus lots of others, plus others discussing the need for configurable concurrency limits (e.g. limit to 2 concurrent jobs). |
Beta Was this translation helpful? Give feedback.
-
|
+1 - 'concurrency' implementation lacks a few important features. |
Beta Was this translation helpful? Give feedback.
-
|
Agreed, this is a very important lack. I find it very surprising that GitHub's pipeline lacks the ability to manage queues |
Beta Was this translation helpful? Give feedback.
-
|
My use case: I've got expensive e2e tests that I only want to run one master copy of at a time to leave headroom for all the PRs that might need the resources. I want to run on every master commit so we can easily bisect when they break. We have multiple commits per hour during working hours. |
Beta Was this translation helpful? Give feedback.
-
|
How come pending jobs with concurrency are being cancelled? most of us will want all of them to await running and not be cancelled by new triggers. This feature is very lacking as is and missing a very strong use case for customers, can we get some insight on this? |
Beta Was this translation helpful? Give feedback.
-
|
Same here. We need the option Our use case: We have e2e tests that run against the same server and cannot run in parallel. Any e2e workflow should only start when no other e2e workflows are running. Concurrency would be the solution if there is an option to not cancel pending jobs. |
Beta Was this translation helpful? Give feedback.
-
|
+1 need a waitting list |
Beta Was this translation helpful? Give feedback.
-
|
Mature CICD solutions (Azure Devops, CircleCI) have this solution, see here for Devops implementation: https://learn.microsoft.com/en-us/azure/devops/release-notes/2021/sprint-190-update +1 to having |
Beta Was this translation helpful? Give feedback.
-
|
Any updates on this one? |
Beta Was this translation helpful? Give feedback.
-
|
+1 to having cancel-pending: false |
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
|
Does anyone have a clever workaround to not having support for |
Beta Was this translation helpful? Give feedback.
-
|
I have worked around by checking the status of last 50 jobs/runs for workflow ID(s), for all those without the status "completed", check the created_at timestamp, and essentially sleep and loop until all of the non-completed runs with an older timestamp are completed. The caveat here is your queued jobs are sleeping and using compute time. I'm not using the concurrency feature at all now In my case I have a workflow that does some changes, creates a PR and merges to main. The reason I have to queue is because Github API rate limiting, there is the option for merge queues however even creating a PR is limited by Githubs secondary api rate limit for a single user/account, basically you cannot do any parallel api calls to Github and their documentation strongly advises against it. Which is why i find it bizarre there is no native queuing option/serial run option. It works ok for small time consuming jobs, but for longer jobs you may not want them to be sleeping for a long time |
Beta Was this translation helpful? Give feedback.
-
|
+1 to having cancel-pending: false or any other naming flag for this |
Beta Was this translation helpful? Give feedback.
-
|
+1 for "cancel-pending: false" This feature would be incredibly useful for us as our automated test infra pretty often skips over tests when using concurrency. While we can come up with a way to enforce concurrency inside the tests themselves, that is pretty involved (and has the risk of running into timeouts). Github's feature is so close to being really useful |
Beta Was this translation helpful? Give feedback.
-
|
We need this so bad. Currently, running terraform plans and applies needs constant attention. If someone posts a PR during infra apply, there goes rest of the components. |
Beta Was this translation helpful? Give feedback.
-
|
+1 we have a very busy pipeline being triggered very often, so we've got a lot of this type of errors. |
Beta Was this translation helpful? Give feedback.
-
|
This is required when using merge-queue. The merge queue maximum parallel runs must be set to max 2, so it does not cancel intermediate runs. It is far from optimal but as almost everything on Github.. it is a workaround. |
Beta Was this translation helpful? Give feedback.
and others
-
Better discussion:
https://github.com/orgs/community/discussions/12835
Select Topic Area
Product Feedback, Question
Body
We recently introduced concurrency for our release workflow at Ryujinx , so we could merge PRs without waiting for the previous release job to finish.
We expected all new workflows to be pending until the previous job is done, but that wasn't the case.
As you can see here, the first job gets canceled after a new pending job gets added, which we wanted to avoid.
We never defined a "priority" or anything to make it cancel this workflow, but it still did.
Reading the documentation again we found this sentence:
Source: Github workflow concurrency
Now this job was already in progress, but was canceled anyway, so we aren't sure if this note applies to our situation.
cancel-in-progress: trueis obviously not defined in our workflow file, so this situation is a little confusing.If this is intended is there a way for us to not cancel previously in-progress workflows? We would prefer to run these workflows in the order they were queued in, so our changelog matches with the actual releases we publish.
(cc: @marysaka)
Beta Was this translation helpful? Give feedback.
All reactions