Skip to content

Self-kill strategy for even better cancellation #13

@vlsi

Description

@vlsi

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?

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions