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?
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:
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?