Avoid re-running wokflow for the same commit #27031

amezin · 2021-07-02T09:15:55Z

amezin
Jul 2, 2021

With on: push a workflow sometimes runs multiple times for the same commit (pushed as a branch and then a tag, or fast-forward merge). Is there a way to avoid this (for one specific workflow)? I. e. don’t run the workflow if it already ran for the same commit id.

Answered by shrink

Jul 2, 2021

Yes, you can use the Check Runs API to identify Workflow runs for a ref. As luck would have it, someone has already built a comprehensive Action for this use-case: fkirc/skip-duplicate-actions.

Add a new “pre” job to your Workflow, this job uses fkirc/skip-duplicate-actions to determine if your main job should be skipped
Add a condition to your main job using the should_skip output of the “pre” job.

For example, adapted from the fkirc/skip-duplicate-actions readme:

jobs:
  pre_job:
    runs-on: ubuntu-latest
    outputs:
      should_skip: ${{ steps.skip_check.outputs.should_skip }}
    steps:
      - id: skip_check
        uses: fkirc/skip-duplicate-actions@v3.4.0
        with:
       …

View full answer

shrink · 2021-07-02T10:58:00Z

shrink
Jul 2, 2021

Yes, you can use the Check Runs API to identify Workflow runs for a ref. As luck would have it, someone has already built a comprehensive Action for this use-case: fkirc/skip-duplicate-actions.

Add a new “pre” job to your Workflow, this job uses fkirc/skip-duplicate-actions to determine if your main job should be skipped
Add a condition to your main job using the should_skip output of the “pre” job.

For example, adapted from the fkirc/skip-duplicate-actions readme:

jobs:
  pre_job:
    runs-on: ubuntu-latest
    outputs:
      should_skip: ${{ steps.skip_check.outputs.should_skip }}
    steps:
      - id: skip_check
        uses: fkirc/skip-duplicate-actions@v3.4.0
        with:
          skip_after_successful_duplicate: 'true'
  main_job:
    needs: pre_job
    if: ${{ needs.pre_job.outputs.should_skip != 'true' }}
    runs-on: ubuntu-latest
    steps:
      - run: echo "Running slow tests..." && sleep 30

0 replies

jsoref · 2021-07-04T03:36:14Z

jsoref
Jul 4, 2021

I use:

on:
  push:
    branches:
      - "**"
    tags-ignore:
      - "**"

Technically if someone pushed a second branch for the same commit, it’d run, but mostly it guards against tags triggering a thing again.

0 replies

kmturley · 2025-12-03T05:11:05Z

kmturley
Dec 3, 2025

I think what's confusing is that you want to show the result of tests in your PR.

So you add the pull_request event, but that creates the duplicate run:

name: Test
on:
  push:
  pull_request:

Results in:

However if you remove pull_request event you still see the Test results in the PR, without duplicates:

name: Test
on:
  push:

Results in:

2 replies

jsoref Dec 3, 2025

There isn't much you can do about that (essentially it's a training issue).
For check-spelling, I implemented suppress_push_for_open_pull_request which does some magic to identify if there's an open PR in the same repository and will skip doing the work (which may not be proper if there's a live PR where the merge product is what matters).

Also, as the minimum billing unit is 1m, there's really very little you can/show do about it.

kmturley Dec 5, 2025

I use this in my repos:

on:
  push:
    branches-ignore:
      - main
    tags-ignore:
      - 'v*'

Which only runs the workflow once on git push which is usually a group of commits.
Then it is never run again, even if a PR is opened, merged or a tag is pushed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

GitHub Community

Avoid re-running wokflow for the same commit #27031

Uh oh!

{{title}}

Uh oh!

Replies: 3 comments 2 replies

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Select a reply

Uh oh!

GitHub Community

Avoid re-running wokflow for the same commit #27031

Uh oh!

amezin Jul 2, 2021

Replies: 3 comments · 2 replies

Uh oh!

shrink Jul 2, 2021

Uh oh!

jsoref Jul 4, 2021

Uh oh!

kmturley Dec 3, 2025

Uh oh!

jsoref Dec 3, 2025

Uh oh!

kmturley Dec 5, 2025

amezin
Jul 2, 2021

Replies: 3 comments 2 replies

shrink
Jul 2, 2021

jsoref
Jul 4, 2021

kmturley
Dec 3, 2025