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]


Reply via email to