styfle / cancel-workflow-action Goto Github PK

Our setup requires all workflows to run on default branch, where each workflow will pull different branch to work with. Is it possible to give each workflow some ID that can be cancel by same ID workflow as an extra parameter?

in Orange we have been using this action as part of a cleanup workflow. It mostly works as expected but sometimes randomly crashes with reasons unknown to me. Do you have any idea why this happens? Maybe I'm missing something?

For example:

##[section]Starting: Request a runner to run this job
Requesting a hosted runner in current repository's account/organization with labels: 'ubuntu-latest', require runner match: True
Labels matched hosted runners has been found, waiting for one of them get assigned for this job.
##[section]Finishing: Request a runner to run this job
Current runner version: '2.165.2'
Prepare workflow directory
Prepare all required actions
Download action repository 'styfle/[email protected]'
##[group]Run styfle/[email protected]
with:
  workflow_id: 685155
  access_token: ***
##[endgroup]
{
  eventName: 'pull_request',
  sha: 'ec557e454da103157a8bc4f9075c2cafa25624e5',
  headSha: '8b2131a087bbae849426a8cb2ff9303dea65c652',
  branch: 'fix-setitem',
  owner: 'biolab',
  repo: 'orange3'
}
Found input: 685155
Found token: yes
Found 4 runs total.
Found 1 runs in progress.
Cancelling another run:  {
  id: 63746056,
  head_sha: '890513eadd90f58c726c934afee1ea0dece92269',
  status: 'in_progress'
}
##[error]Resource not accessible by integration
Cleaning up orphan processes

We had an issue today where a developer was having their build mysteriously cancelled part way through their CI run. Eventually I realised they were pushing to a branch that had almost the same name and that was enough to trigger this action to cancel the job.

A rough timeline of what happened:

• Developer pushes to branch-name-1
• CI begins work, this action searches for jobs but doesn't find any so job goes ahead
• Developer pushes to branch-name
• CI begins work, this action searches for jobs on branch-name but the currently executing job for branch-name-1 is returned instead and it cancels that

I have created a PR which I believe will fix this issue: JimmehAH#1

It would be great if this action could allow for :workflow_file_name as an alternative to :workflow_id.

This seems to be support by the API and github's javascript library as specified in https://developer.github.com/v3/actions/workflows/#get-a-workflow and would avoid having to make seperate API calls to find out the ID.

A question. I've recently been trying to get my CI to be more efficient. As such, I'm experimenting with "Don't run expensive sub-jobs if a certain label is present" sort of thing. As such, to be safe, the top of my workflow is:

name: Build Tests
on:
  pull_request:
    types: [opened, synchronize, reopened, labeled, unlabeled]

because I want to capture if a label changes whether I need to spin up a different test. But my guess is this nice action doesn't notice label changes:

That was from me adding then removing then adding my special label. And as such, CI built up even though my workflow steps have:

name: Build Tests
on:
  pull_request:
    types: [opened, synchronize, reopened, labeled, unlabeled]
jobs:
  build_test_mapl:
    name: Build and Test MAPL
    runs-on: ubuntu-latest
    container: gmao/geos-build-env-gcc-source:6.0.13-openmpi_4.0.3-gcc_9.3.0
    steps:
      - name: Cancel Previous Runs
        uses: styfle/[email protected]
        with:
          access_token: ${{ github.token }}
      - name: Checkout
        uses: actions/checkout@v2
        with:
          fetch-depth: 1
...
  build_gcm:
    name: Build GEOSgcm
    if: "!contains(github.event.pull_request.labels.*.name, '0 diff trivial')"
    runs-on: ubuntu-latest
    container: gmao/geos-build-env-gcc-source:6.0.13-openmpi_4.0.3-gcc_9.3.0
    steps:
      - name: Cancel Previous Runs
        uses: styfle/[email protected]
        with:
          access_token: ${{ github.token }}
      - name: Checkout GCM
        uses: actions/checkout@v2
        with:

Am I right in my assessment? Or do I need some more bits in this? In the end, everything works out I suppose. But that expensive test is 30 minutes and I'd rather spare GitHub/Microsoft from running it if not needed. 😄

Here is the output of 2 runs, one started after the other, and it's finding no runs with the same owner, repo, workflow id and branch

{
  eventName: 'push',
  sha: 'd38a27d91a05f052c5a2a2697ad8e5cf9dd9e155',
  headSha: 'd38a27d91a05f052c5a2a2697ad8e5cf9dd9e155',
  branch: '2235-cancel-previous-pr-workflows-when-a-new-commit-is-pushed',
  owner: 'palmetto',
  repo: 'palmetto-website',
  GITHUB_RUN_ID: '2162729129'
}
Found token: yes
Found workflow_id: ["5864657"]
Found 0 runs total.
Found 0 runs to cancel.

{
  eventName: 'push',
  sha: '1cb75f12f80a1d92e15abe513e30c75f01d83563',
  headSha: '1cb75f12f80a1d92e15abe513e30c75f01d83563',
  branch: '2235-cancel-previous-pr-workflows-when-a-new-commit-is-pushed',
  owner: 'palmetto',
  repo: 'palmetto-website',
  GITHUB_RUN_ID: '2162727587'
}
Found token: yes
Found workflow_id: ["5864657"]
Found 0 runs total.
Found 0 runs to cancel.

I was just thinking about, but it would be awesome if when this action runs (successfully canceling a previous run) it would set an environment variable that can be picked up by other steps to trigger cleanup steps?

It might be possible, that you don't know your workflow id, or you updated it. But, again, that would lead to updating the cancel workflow. This can be solved if the README notes down the additional steps to extract all workflows, and then cancel them.

Do I need to configure anything else to make this work on PRs and master?

Hello! This is a great idea!

I wonder if anyone would know of an alternative for Azure Pipelines?

Scenario: If I merge few commits to master branch quickly some of them will get canceled. But I want all of them to execute.
Suggestion: I'd like to have option to specify protected branches where canceling doesn't happen.

GitHub has announced that workflows "now support a concurrency key at both the workflow and job level that will ensure that only a single run or job is in progress". The syntax documentation has already been updated:

# Example using concurrency to cancel any in-progress job or run
concurrency: 
  group: ${{ github.head_ref }}
  cancel-in-progress: true

I'm wondering if it would be helpful to document in the readme what the differences are and which implementation might be more useful depending on use cases. I think this will be helpful for anyone currently using this action and thinking about switching but even for new users. Any thoughts?

I have a setup based on workflow_run. You can see it here. For whatever reason, when running, the job seems to cancel itself as opposed to the workflow that triggered it. My setup seems to be very simple so I'm wondering if I'm missing something obvious/fundamental.

The cancel workflow run API returns HTTP 202 Accepted, but the run isn't actually cancelled until some time later.

If I really need two runs not to overlap, I should wait until the cancelled runs have actually stopped before continuing.

I'd like to propose adding something like a wait option (defaulting to false) that polls the state of the cancelled runs and only completes the action once they are no longer in_progress.

Hello

Thank you for publishing this action!

This is more of a request for ideas rather than a bug report.
Is there a way to avoid the need for the github token as a secret? Secrets are not available, rightly so, to forks. This means that in practice a project accepting pull requests from forks cannot implement cancel-workflow-action that would work.

I'm really open to any idea that would make it work.

When this action is running, it prints a lot of stuff, like total runs and event data etc....
If printing these details is necessary, you can group logs and make it look properly instead of now which looks completely messy.

For quick reference : Grouping log lines

Thanks for awesome action which makes our workflows more cooler. 😎

Before	After

I'm facing a situation where I've multiple workflows I would like to cancel.

Obviously I can just call this action multiple times 😄 but wondered if it's smart/possible to provide an array of IDs of workflows to cancel?

thanks!

See https://github.com/MirahezeBots/MirahezeBots/pull/513/checks?check_run_id=2540803138

Canceling all non-matching SHAs has the downside that from time to time the cancel-workflow-action will actually cancel workflow that are newer.

Example: If the CI get triggered for a commit (SHA1) and uses more than 10 jobs, some jobs will get queued (incl. a cancel action for all commits != SHA1), then the user pushes new commit (SHA2) and even more jobs get queued. At some point the cancel-workflow-action (for SHA1) finally gets run and it will cancel the workflow for SHA2, that is actually the more recent one.

Maybe you could check the dates in created_at and only cancel the non-recent ones, so canceling by create time instead of SHA.

I have a GHA setup where multiple workflows can be started depending on github action. In my case, a commit to an open PR starts a build workflow, while closing the PR starts a teardown workflow.
When a user pushes a commit to an open PR, and then quickly merges the PR, my workflows are out of order (build workflow lasts longer, so teardown workflow finishes first).
The main issue here is that both of those workflows have the same branch and commit hash (only different action).

Would it be possible to add an option to cancel-workflow-action, so that the action cancels all workflows for its branch (including ones with the same commit hash), except the current workflow (the one that actually executes cancel-workflow-action)?

From the README:
When you git push, this GitHub Action will capture the current Branch and SHA. It will query GitHub's API to find previous workflow runs that match the Branch but do not match the SHA. These in-progress runs will be canceled leaving only the latest run.

Is it possible to add a feature where it captures the user instead of branch? I'd like to be able to limit a user to X number of workflow runs. Where I work we have self-hosted runners and certain people like to do what I call "machine gun commit and push" (different branches) which eats up all available capacity.

How can we avoid receiving email notifications for each cancelled workflow?

@HelgeGehring

I have tried using workflow file names in my cancel.yml. However none of workflows seem to be identified when running via the file name.

Here is my cancel.yml file:

name: cancel
on: [push]
jobs:
  cancel:
    name: 'Cancel Previous Runs'
    runs-on: ubuntu-latest
    timeout-minutes: 3
    steps:
      - uses: styfle/[email protected]
        with:
          workflow_id: 'app.yml, app-deploy.yml, proxy-deploy.yml'
          access_token: ${{ github.token }}

When I replaced the workflow file names with the workflow IDs the running actions were canceled as expected. I also had a look at the source and did not see any conversion from file name to workflow ID.

Maybe I'm not understanding how to use the file names so any info here would be appreciated.

I'm not sure where this is coming from, but from time to time the action fails with "Error: Not Found", Output is as follows:

Can we ensure, even if "something" is not found, that the action does not fail? In my case it would be okay even if the action fails internally, that it reports just a warning instead of failing?

Hello,

This workflow currently gives the following warning:

Node.js 12 actions are deprecated. For more information see: https://github.blog/changelog/2022-09-22-github-actions-all-actions-will-begin-running-on-node16-instead-of-node12/. Please update the following actions to use Node.js 16: styfle/cancel-workflow-action

Would it be possible to update this action to use Node 16 instead of 12?

Thanks!!

We have a deploy workflow including tests after the build-main job and some stuff that happens before the build-main job.
My question is: can we cancel previous workflows only when the build-main job (in current running workflow) has not been started yet OR the build-main job has been finished?

example:

jobs:
  prepare:
     # do some preparation; workflow can be skipped

  build-main:
     needs:
        - prepare
     # do NOT skip workflow when build-main is running...

  run-tests:
     needs:
        - build-main
     # run tests; workflow can be skipped

ignore_sha and all_but_latest option is got with getInput method, but there is getBooleanInput.
ref: https://github.com/actions/toolkit/tree/main/packages/core#inputsoutputs

The GitHub token can be set as default (wasn't possible in the distant past, I think, but now is and several of the core actions/ now do this, along with a growing number of 3rd party actions). This would make the action a bit less verbose for normal use.

See https://github.com/actions/checkout/blob/5a4ac9002d0be2fb38bd78e4b4dbde5606d7042f/action.yml#L24 for example.

Issue:

I followed ur steps correctly (it would give me an error if I don't have a workflow ID or a token).

It does not cancel my other running workflows (I did make a local change and pushed to test it, in order to have 2 running workflows). Let me add the log and the code I am using:

name: Firebase Deploy Prod

on:
  push:
    branches: [ master ]
  pull_request:
    branches: [ master ]

jobs:
  cancel:
    name: 'Cancel Previous Runs'
    runs-on: ubuntu-latest
    timeout-minutes: 3
    steps:
      - uses: styfle/[email protected]
        with:
          # ID of this workflow        
          workflow_id: XXXXXX
          access_token: ${{ secrets.GH_WORKFLOW_TOKEN }}
  build:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        node-version: [13.x]

    steps:
    - uses: actions/checkout@v2
    - name: Use Node.js ${{ matrix.node-version }}
      uses: actions/setup-node@v1
      with:
        node-version: ${{ matrix.node-version }}
    - run: npm i
    - run: npm run lint
    - run: npm run lint:scss
    - run: npm run build
    - name: Deploy to Firebase
      uses: w9jds/firebase-action@master
      with:
        args: deploy
      env:
          FIREBASE_TOKEN: ${{ secrets.FIREBASE_TOKEN }}

Plz help =S, I would really that feature =D

I added this action to my workflows, but I have a lot of them. Then I realised an important limitation of this tool: if your pipeline is saturated, this action won't be scheduled. This means that the behaviour is a bit different from what you might get on, e.g., Travis CI, where the scheduler terminates stale workflows, thus clearing a saturated pipeline for CI to immediately start working on the new commit.

It may be helpful to document this limitation.

Our master branch workflow is separated into CI and CD jobs.

Is there a possibility for this action not to cancel previous workflows if they have already reached the CD stage?

Hi,
when trying to integrate the action into an open-source project i got the following log:

Found workflow_id: ["1234"]
Found 6 runs total.
Found 2 runs in progress.
Cancelling another run:  {
  id: 1234,
  head_sha: '1234',
  status: 'in_progress'
}
Error while cancelling workflow_id 1234: Resource not accessible by integration
Cancel Complete.

Background is that i try to integrate the action from a fork into the main repo. The action is not resulting into an error state.
It seems that the creator of the PR is not allowed to fetch the status of the workflows running in the main repo due to access restrictions. Is for forked projects maybe a solution available?

Could this not be used to auto-detect the workflow id using the workflow name string in github.workflow? https://developer.github.com/v3/actions/workflows/

We just got an API rate limit exceeded for installation ID xxxx, as far as I understand it's because this action uses the search API which has a low rate limit. It'd be great though if it would just soft-fail in this case and not fail the whole workflow.

We generally like to cancel previous workflows, but not at the cost of failing random workflows due to API failures.

Would it be possible to only cancel workflow runs with a smaller id, to avoid cancelling succeeding/future runs (already scheduled e.g. 10 seconds later) that would replace the result of the current one?

I might be missing something super obvious but is there any way to cancel the current run?
The use case is that I've got longer running parallel jobs and if either of them fail I'd like to stop the whole workflow.

It would be great to document what on: x events this action can work on.
As far as I can see, it will only work on workflows that are triggered by on: push (maybe also `on: pull_request).

For instance, I have a workflow that is triggered on: workflow_dispatch with a series of inputs (one being sha), but I can't imagine that adding this Action to my steps will work as intended, because it relies on github.sha which isn't present in a workflow_dispatch event.

Issue: cancel [email protected] doesn't cancel other workflows. So I end up with concurrent deployments happening at the same time.

This is the console output:

Found token: yes
Found workflow_id: ["2407268"]
Found 30 runs for workflow 2407268 on branch master
- https://github.com/peakflo/peakflo-web/actions/runs/607443183
- https://github.com/peakflo/peakflo-web/actions/runs/606856692
- https://github.com/peakflo/peakflo-web/actions/runs/606853199
- https://github.com/peakflo/peakflo-web/actions/runs/605249771
- https://github.com/peakflo/peakflo-web/actions/runs/603081542
- https://github.com/peakflo/peakflo-web/actions/runs/603017231
- https://github.com/peakflo/peakflo-web/actions/runs/602560077
- https://github.com/peakflo/peakflo-web/actions/runs/602505389
- https://github.com/peakflo/peakflo-web/actions/runs/602107255
- https://github.com/peakflo/peakflo-web/actions/runs/600101030
- https://github.com/peakflo/peakflo-web/actions/runs/599948638
- https://github.com/peakflo/peakflo-web/actions/runs/596337062
- https://github.com/peakflo/peakflo-web/actions/runs/596102703
- https://github.com/peakflo/peakflo-web/actions/runs/595980502
- https://github.com/peakflo/peakflo-web/actions/runs/595932749
- https://github.com/peakflo/peakflo-web/actions/runs/595662549
- https://github.com/peakflo/peakflo-web/actions/runs/595615314
- https://github.com/peakflo/peakflo-web/actions/runs/595553798
- https://github.com/peakflo/peakflo-web/actions/runs/594610473
- https://github.com/peakflo/peakflo-web/actions/runs/591971936
- https://github.com/peakflo/peakflo-web/actions/runs/591930848
- https://github.com/peakflo/peakflo-web/actions/runs/586060064
- https://github.com/peakflo/peakflo-web/actions/runs/586036204
- https://github.com/peakflo/peakflo-web/actions/runs/583869636
- https://github.com/peakflo/peakflo-web/actions/runs/583755045
- https://github.com/peakflo/peakflo-web/actions/runs/580871834
- https://github.com/peakflo/peakflo-web/actions/runs/577288737
- https://github.com/peakflo/peakflo-web/actions/runs/574666087
- https://github.com/peakflo/peakflo-web/actions/runs/574665148
- https://github.com/peakflo/peakflo-web/actions/runs/574664704
with 0 runs to cancel.

Cancel Complete.

My deploy.yml looks the following way:

jobs:
  deploy:
    name: Deploy
    runs-on: ubuntu-latest
    steps:
      - name: Cancel Previous Runs
        uses: styfle/[email protected]
        with:
          access_token: ${{ github.token }}

Screenshot: https://kceb.d.pr/iao4AT

For some reason it finds the workflow, tries to cancel it, then errors and says it can't find the workflow. My workflow ends up not being cancelled

Current documentation:

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - name: Cancel Previous Runs
        uses: styfle/[email protected]
        with:
          access_token: ${{ github.token }}
      #- name: Run Tests
      #  uses: actions/setup-node@v1
      #  run: node test.js
      # ... etc

But my workflow is more like:

jobs:
  test1:
    ...
  test2:
    ...

Do I define a new job (say, we name it cancelothers) to only run this action and define a needs: cancelothers in test1 and test2 individually? Or do I have this action as the first step in just one of them? Or both of them?

Hope you can advise. Thanks!

I'm using the cancel github action for my test. However, this cancel unittest run from the main branch:

As seen on the above image, our tests were green in the main branch, but due to the cancel action, our tests switch to red:

After the unittests from the main branch get canceled, our unittests are marked as failed:

How can I filter the cancel action such as unittests in main branch are never canceled ? if: {{ github.ref_name == 'main' }} doesn't work as other branch could still cancel the main workflow.

I can't adequately explain it, but currently the only explanation I have for the behavior I just saw is that this line is not filtering runs from other branches:

Specifically this happened in an "all_but_latest" self-cancelling config:

1- workflow run on a PR from a branch starts
2- I merge to master branch (triggers another run)
3- I merge again to master branch (triggers another run)

Run 3 cancelled 1 and 2 even though 1 was on another branch

It looks like the workflow_id is not a parameter that the octokit API call accepts, but branch definitely is
https://docs.github.com/en/[email protected]/rest/reference/actions#list-workflow-runs-for-a-repository--parameters

The current run ids would not match, the head_shas did not match, nothing matched so they didn't get filtered - thus my only guess is that the repo workflow list call was expected to filter on branch but clearly did not, which is unexpected.

🤔

how can we make a cancelled workflow count as skip instead of failed?

https://github.com/gdsfactory/gdsfactory/actions/runs/2799032426

I'm a new user of the action and was very confused when I landed on the page here when searching the GitHub Action marketplace.

The version in the details says 0.9.1, but at the top of the page it says 0.6.0 and clicking the "Use latest version" in the top-right presents me with a line that also contains 0.6.0.

I can see here in the repo that 0.9.1 is the latest version.

So I'm not sure what isn't syncing on the GitHub side, but wanted to let you know in case it was in your control to fix this. I imagine many folks will start using 0.6.0 until this is addressed.

If previous runs are waiting for a manual approval then they are not cancelled.

Hi.

I implemented it in my fork, but for some reason the previous workflows don't stop if I updated the PR.
Part of main.yml:

name: CI
on:
  push:
    branches:
      - 'master'
      - 'develop'
  pull_request:
    branches:
      - '*'
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - name: Cancel previous runs
        uses: styfle/[email protected]
        with:
          access_token: ${{ github.token }}
      - uses: actions/checkout@v2
      ...

cancel.yml:

name: Cancel
on:
  workflow_run:
    workflows: ["CI"]
    types:
      - requested
jobs:
  cancel:
    runs-on: ubuntu-latest
    steps:
    - uses: styfle/[email protected]
      with:
        workflow_id: ${{ github.event.workflow.id }}

When creating a PR from the current repository, it works fine.
But when creating a PR from a fork. No reaction.
From main.yml I got an error:

Found 6 runs for workflow 4551668 on branch check-workflow-canceling
- https://github.com/dvkruchinin/cvat/actions/runs/726508310
- https://github.com/dvkruchinin/cvat/actions/runs/726502076
- https://github.com/dvkruchinin/cvat/actions/runs/726489962
- https://github.com/dvkruchinin/cvat/actions/runs/726361555
- https://github.com/dvkruchinin/cvat/actions/runs/726315700
- https://github.com/dvkruchinin/cvat/actions/runs/726311604
with 2 runs to cancel.
Canceling run:  {
  id: 726502076,
  head_sha: '49509b67436b6704a7151bcdfd670e2b079622d4',
  status: 'in_progress',
  html_url: 'https://github.com/dvkruchinin/cvat/actions/runs/726502076'
}
Error while canceling workflow_id 4551668: Resource not accessible by integration

Please tell me what I'm doing wrong?

Hello!

About 12:00 UTC today action stopped working with error:

Run styfle/[email protected]
{
  eventName: 'push',
  sha: 'd14b***1f1b8',
  headSha: 'd14b***1f1b8',
  branch: '***',
  owner: '***',
  repo: '***',
  GITHUB_RUN_ID: '119****313'
}
Found token: yes
Error: Not Found

Config is the same everywhere

- name: Cancel Previous Runs
   uses: styfle/[email protected]
   with:
      access_token: ${{ secrets.WORKFLOW_TOKEN }}

This affects all workflow where used and all repos.

Also tested version 0.8.0, error is the same

Maybe retiring this in favor of https://docs.github.com/en/actions/using-jobs/using-concurrency ?

It's possible to customise the GITHUB_TOKEN permissions now. Would be great to document which permissions this action needs.

I think it might be just

permissions:
  - actions: write

?

Scenario: I have a content branch and a master branch. An identical workflow runs in case of push to either branches, resulting in race condition.

Expection: I would like to be able to cancel prior workflow runs irrespective of the branch. README file makes me think that this is currently not supported -

this GitHub Action will capture the current Branch and SHA. It will query GitHub's API to find previous workflow runs that match the Branch but do not match the SHA.

Example of the race conditions I want to avoid with this feature (from here):