From 3f732de7373110ace759279f16752eba1334eaa9 Mon Sep 17 00:00:00 2001 From: "Jason T. Greene" Date: Wed, 19 Feb 2020 00:39:53 -0600 Subject: [PATCH] Update README.md --- README.md | 29 +++++++++++++++++++++++++---- 1 file changed, 25 insertions(+), 4 deletions(-) diff --git a/README.md b/README.md index 76a856f..c357988 100644 --- a/README.md +++ b/README.md @@ -1,25 +1,46 @@ # cancel-previous-runs -[**BETA**] This action cancels all previous runs on the same branch, effectively limiting the resource consumption of the workflow using this action to one run per branch. +[**BETA**] This action cancels previous runs for one or more branches/prs associated with a workflow, effectively limiting the resource consumption of the workflow to one per branch.

typescript-action status ## Usage -This action should be placed as an early step in your workflow (e.g. after chekout), so that it can abort the other running jobs before consuming additional capacity. Additionally, it requires that the running Github Action token (located in the secrets context) be passed as an input parameter so that it can list and cancel workflow runs associated with the workflow's repository. +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 interrval 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 chekout), so that it can abort the other previously running jobs immediatily, in case most resources are tied up. Unfortunately this approach is a no-op wheen 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 peermissions for security reasons. write permissions are required 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. ### Inputs token - The github token passed from `${{ secrets.GITHUB_TOKEN }}`. Since workflow files are visible in the repository, **DO NOT HARDODE A TOKEN ONLY USE A REFERENCE**. +workflow - The filename of the workflow to limit runs on (only applies to schedule events) + + +### Schedule Example + +```yaml +name: Cleanup Duplicate Branches and PRs +on: + schedule: + - cron: '*/15 * * * *' +cancel-runs: + runs-on: ubuntu-latest + steps: + - uses: n1hility/cancel-previous-runs@v2 + with: + token: ${{ secrets.GITHUB_TOKEN }} + workflow: my-heavy-workflow.yml +``` + -### Example +### Alternate/Fallback Example ```yaml test: runs-on: ubuntu-latest steps: - uses: actions/checkout@v1 - - uses: n1hility/cancel-previous-runs@v1 + - uses: n1hility/cancel-previous-runs@v2 with: token: ${{ secrets.GITHUB_TOKEN }} ```