potiuk edited a comment on issue #9479: URL: https://github.com/apache/pulsar/issues/9479#issuecomment-773985961
> @potiuk Is there a mode where one could limit "killing of the duplicates" to the same branch as the new triggered workflow run? Yes. The `duplicates` mode works this way (see docs below). It was the original mode it worked on by default but it is not really effective in the "high strain" situation as it turned out, and that's why I introduced `allDuplicates`. Why this is not a good idea to use `duplicates` while we are having the "high queue strain" problem? Because of the way how workflows are queued. The `allDuplicates` mode have been introduced precisely to tackle the "high queue strain" problem. Problem with using the action is that it has to actually start running to cancel anything. And if you have a "strain" on the GitHub Action Queue, your "cancel" workflow might simply be queued for hours because other jobs will occupy the queue. So the past "duplicates" from the same branch will not be cancelled effectively because the job to cancel them will only run hours later after those duplicates have finished. If we really want to be "queue conscious", I honestly cannot imagine a situation where you would like to wait for previous build from the same branch to complete when you already have a new one queued. Yeah you will see the result later, but there is probably a reason why you pushed new changes to that branch and what you are really interested in eventually is to see the results of the build for the "newest" commit in that branch, not the previous ones. And yeah - it means that you might see some partial results of it later, but this is what I consider as being "nice" to others. When you push new version of the same PR, cancelling any (even already running) version of that PR is simply a very nice gesture for the others, because you will anyhow have to look at the result of the newer commits. That's why the `allDuplicates` is much better approach IMHO. It is more aggressive, yes, but also it is much more efficient. Whenever ANY cancel jobs will run, it will cancel ALL duplicates from ALL branches there - therefore it makes all people who push more than one change successively pushing changes to their PRs to ONLY use the job time for the last version of the commit they pushed (in the "strain" situation). I think this is really the best way to proceed. Here, relevant part from the original documentation from https://github.com/potiuk/cancel-workflow-runs The job cancel modes work as follows: Cancel Mode | No sourceRunId specified | The sourceRunId set to ${{ github.event.workflow_run.id }} -- | -- | -- duplicates | Cancels duplicate runs from the same repo/branch as current run. | Cancels duplicate runs for the same repo/branch as the source run. allDuplicates | Cancels duplicate runs from all running workflows. | Cancels duplicate runs from all running workflows. self | Cancels self run. | Cancel the sourceRunId run. failedJobs | Cancels all runs of own workflow that have matching jobs that failed. | Cancels all runs of the sourceRunId workflow that have matching jobs that failed. namedJobs | Cancels all runs of own workflow that have matching jobs. | Cancels all runs of the sourceRunId workflow that have matching jobs. allDuplicatedNamedJobs | Cancels all duplicate runs of own workflow that share matching jobs pattern. | Cancels all runs of the sourceRunId workflow that share matching job pattern. ---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: [email protected]
