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:
- Make users add "cancellation" job to their workflows
- 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?