commit | 9fd86165ce7966ab9e9277f9603e281b8ae8bbca | [log] [tgz] |
---|---|---|
author | Jarek Potiuk <jarek@potiuk.com> | Sun Jul 26 17:01:53 2020 +0200 |
committer | Jarek Potiuk <jarek@potiuk.com> | Sun Jul 26 17:01:53 2020 +0200 |
tree | 1cca8b031dd502f2efec453d6a3ad2f6d7e65c32 | |
parent | f0bf36ae0bb733d9cdd659316aaf3d2003b09366 [diff] |
Fixed docs
This action cancels runs for one or more branches/prs associated with a workflow, effectively limiting the resource consumption of the workflow to one per branch.
It also cancels workflows from the latest workflow run if specified jobs failed. That allows to further limit the resource usage of running workflows, without impacting the elapsed time of successful workflow runs. Typical behaviour of the Github Actions Workflow is that the success/failure propagation between the jobs happens through job dependency graph (needs: in the GA yaml). However, there are cases where you want to start some jobs without waiting for other jobs to succeed, yet if the other jobs fail, you want to cancel the whole workflow. It's similar to fail-fast behaviour of the matrix builds.
Since cancelling workflow does not work from “fork” pull requests for security reasons, the capability of canceling the workflows should be built in the scheduled task.
I based the implementation of this action on the n1hility action to cancel the previous runs only.
The easiest and most complete approach to utilize this action, is to create a separate schedule event triggered workflow, which is directed at the workflow you wish to clear duplicate runs. At each cron interval all branches and all PRs executing for either push or pull_request events will be processed and limited to one run per branch/pr.
Additionally, this action can be placed as an early step in your workflow (e.g. after the checkout), so that it can abort the other previously running jobs immediately, in case the workflows tie up most resources. Unfortunately this approach is a no-op when a pull request uses a fork for a source branch. This is because the GITHUB_TOKEN provided to runs with a fork source branch specifies reed-only permissions for security reasons. You need write permissions to be able to cancel a job. Therefore, it's a good idea to only rely on this approach as a fallback in-addition to the previously described scheduling model.
${{ secrets.GITHUB_TOKEN }}
. Since workflow files are visible in the repository, DO NOT HARDCODE A TOKEN ONLY USE A REFERENCE.name: Cleanup Duplicate Branches and PRs on: schedule: - cron: '*/15 * * * *' cancel-runs: # Prevent forks from running this to be nice if: github.repository == 'foo-org/my-repo' runs-on: ubuntu-latest steps: - uses: potiuk/cancel-workflow-runs@v1 with: token: ${{ secrets.GITHUB_TOKEN }} workflow: my-heavy-workflow.yml
This kills all previous runs of the workflow, and also latest run if one of the jobs matching ^Static checks$
and ^Build docs^
or ^Build prod image .*
regexp failed in it.
name: Cleanup Duplicate Branches and fail-fast errors on: schedule: - cron: '*/15 * * * *' cancel-runs: # Prevent forks from running this to be nice if: github.repository == 'foo-org/my-repo' runs-on: ubuntu-latest steps: - uses: potiuk/cancel-workflow-runs@v1 with: token: ${{ secrets.GITHUB_TOKEN }} workflow: my-heavy-workflow.yml failFastJobNames: '["^Static checks$", "^Build docs$", "^Build prod image.*"]'
test: runs-on: ubuntu-latest steps: - uses: actions/checkout@v1 - uses: potiuk/cancel-workflow-runs@v1 with: token: ${{ secrets.GITHUB_TOKEN }}
MIT License covers the scripts and documentation in this project.