n1hility/cancel-previous-runs

Self-kill strategy for even better cancellation

Opened this issue · 0 comments

vlsi commented

Hi,

I evaluate cancel-previous-runs, and it looks like the action does not help much in case jobs take ~10 minutes (which is often the case for Apache Caclite).

I wonder if you have evaluated the following approach:

  1. Make users add "cancellation" job to their workflows
  2. The cancellation job would run in parallel with all the others, and it would fetch PR branch and it would kill the jobs in case the PR branch is updated

In other words, "PR update" can't cancel stale jobs for security reasons, so what if each job verifies once in a while "ok, git fetch, if there are changes, then we terminate in the hope to yield for the newer PR jobs".

Would that work?