Feature Request: Prevent Duplicate Workflow Runs on PR Branches

[kumaakh]

GitHub Actions: Duplicate Workflow Runs on PR Branches (Feature Request)

Summary

When a branch has an open pull request and receives a push, GitHub Actions triggers workflows twice - once for the push event and once for the pull_request synchronize event. There is no clean way to prevent this duplication, leading to wasted CI resources and execution time.

Problem Statement

Current Behavior

Consider a typical CI workflow configuration:

name: CI
on:
  push:
    branches: ["**"]  # Allow developers to validate on any branch
  pull_request:
    branches: [main]   # Validate PRs before merge

Scenario:

1. Developer creates branch feature-x and pushes commits
2. Workflows run on push (as intended) ✅
3. Developer opens PR from feature-x to main
4. Developer pushes another commit to feature-x
5. Both events fire:
   • push event (because branch matches **)
   • pull_request synchronize event (because PR exists)
6. Result: Identical workflows run twice simultaneously ❌

Real-World Impact

In our project (ApraPipes), we have 7 CI workflows covering different platforms:

• Windows (CUDA & no-CUDA)
• Linux (CUDA, no-CUDA, ARM64)
• Linux CUDA (WSL & Docker variants)

Each PR commit triggers 14 workflow runs instead of 7 - a 100% waste of:

• GitHub Actions minutes
• Self-hosted runner capacity
• Developer time waiting for results
• Carbon footprint (for cloud runners)

Average CI time per platform: 2 hours
Wasted time per PR commit: 14 hours of duplicate compute

Why Current Solutions Don't Work

1. Concurrency Groups

Attempted Solution:

concurrency:
  group: ${{ github.workflow }}-${{ github.head_ref || github.ref }}
  cancel-in-progress: true

Why it fails:

The push and pull_request events have different context variables, making it impossible to create identical group identifiers:

Event	github.head_ref	github.ref	Resulting Group
push	"" (empty)	refs/heads/feature-x	CI-refs/heads/feature-x
pull_request	feature-x	refs/pull/123/merge	CI-feature-x

Different groups = Both runs execute in parallel

Even using github.run_id as fallback doesn't help - each event gets a unique run ID, so they never share a group.

2. Conditional Job Execution

Attempted Solution:

jobs:
  build:
    if: github.event_name != 'push' || !github.event.pull_request

Why it fails:

The github.event.pull_request object is only populated during pull_request events. During push events, it's null even if a PR exists for that branch. There's no built-in way to check "does this pushed branch have an open PR?"

3. Restricting Push Triggers

Attempted Solution:

on:
  push:
    branches: [main]  # Only main, not feature branches
  pull_request:
    branches: [main]

Why it's inadequate:

This prevents duplication but breaks developer workflow:

• Developers can't validate feature branches before creating PRs
• Forces premature PR creation just to run CI
• Doesn't support exploratory development

4. GitHub API Check (Workaround)

Possible but painful:

jobs:
  check-pr:
    runs-on: ubuntu-latest
    outputs:
      has-pr: ${{ steps.check.outputs.has_pr }}
    steps:
      - uses: actions/github-script@v7
        id: check
        with:
          script: |
            const prs = await github.rest.pulls.list({
              owner: context.repo.owner,
              repo: context.repo.repo,
              head: `${context.repo.owner}:${context.ref.replace('refs/heads/', '')}`
            });
            return prs.data.length > 0;

  build:
    needs: check-pr
    if: github.event_name == 'pull_request' || needs.check-pr.outputs.has-pr == 'false'

Problems:

• Adds complexity and failure points to every workflow
• Additional API calls and execution time
• Still starts both runs before check completes
• Requires careful permission management
• Not an official, supported pattern

Proposed Solutions

Option A: New Event Filter (Preferred)

Add a built-in event filter to skip push when PR exists:

on:
  push:
    branches: ["**"]
    skip-if-pull-request: true  # NEW: Skip if PR exists for this branch
  pull_request:
    branches: [main]

Benefits:

• Simple, declarative
• No API calls or custom logic
• Clear intent
• Backward compatible (new field is opt-in)

Option B: Enhanced Context Variables

Make PR detection available in push event context:

jobs:
  build:
    if: github.event_name == 'pull_request' || github.push.has_open_pull_request == false

Add to push events:

• github.push.has_open_pull_request (boolean)
• github.push.pull_request_number (number or null)

Option C: Smarter Concurrency Groups

Automatically unify concurrency groups across related events:

concurrency:
  group: ${{ github.workflow }}-${{ github.branch }}  # NEW: Normalized branch name
  cancel-in-progress: true

Where github.branch resolves to the same value for both:

• push to feature-x → feature-x
• pull_request from feature-x → feature-x

Currently impossible because github.ref differs between event types.

Use Cases

This affects any project that wants:

1. ✅ Developers to validate feature branches via push (before PR creation)
2. ✅ Automated PR validation via pull_request event
3. ❌ Without running identical CI twice per PR commit

This is a fundamental CI/CD pattern used across the industry (Jenkins, GitLab CI, CircleCI all handle this better).

Comparison with Other CI Systems

GitLab CI

workflow:
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
    - if: $CI_COMMIT_BRANCH && $CI_OPEN_MERGE_REQUESTS
      when: never
    - if: $CI_COMMIT_BRANCH

Provides explicit control over when pipelines run based on MR existence.

CircleCI

Workflows automatically de-duplicate when both push and pull_request would trigger.

Jenkins (GitHub Branch Source Plugin)

Provides Discover pull requests from origin > Only pull requests vs Both pull requests and branches options with smart de-duplication.

Community Impact

Searching GitHub:

• 500,000+ repositories use both push and pull_request triggers
• Common workaround: Remove push: branches: ["**"] (breaks pre-PR validation)
• Community discussions: 26940, 57827, 26276

This is a well-known pain point affecting thousands of projects.

Conclusion

GitHub Actions needs a first-class solution for preventing duplicate push/pull_request runs. The current workarounds are:

• Complex (API checks)
• Wasteful (accept duplication)
• Limiting (remove push triggers)

None of these are acceptable for production CI/CD at scale.

Request: Please prioritize adding one of the proposed solutions (preferably Option A: skip-if-pull-request filter) to make GitHub Actions competitive with other CI systems in this fundamental use case.

---

Environment:

• Affected: All repositories using both push and pull_request triggers
• Impact: Doubled CI costs and runtime for PR workflows
• Workarounds: None that are both simple and effective

Example Repository: https://github.com/Apra-Labs/ApraPipes/tree/main/.github/workflows

Thank you for considering this improvement to GitHub Actions.

[github-actions[bot]]

💬 Your Product Feedback Has Been Submitted 🎉

Thank you for taking the time to share your insights with us! Your feedback is invaluable as we build a better GitHub experience for all our users.

Here's what you can expect moving forward ⏩

• Your input will be carefully reviewed and cataloged by members of our product teams. 
  • Due to the high volume of submissions, we may not always be able to provide individual responses.
  • Rest assured, your feedback will help chart our course for product improvements.
• Other users may engage with your post, sharing their own perspectives or experiences. 
• GitHub staff may reach out for further clarification or insight. 
  • We may 'Answer' your discussion if there is a current solution, workaround, or roadmap/changelog post related to the feedback.

Where to look to see what's shipping 👀

• Read the Changelog for real-time updates on the latest GitHub features, enhancements, and calls for feedback.
• Explore our Product Roadmap, which details upcoming major releases and initiatives.

What you can do in the meantime 💻

• Upvote and comment on other user feedback Discussions that resonate with you.
• Add more information at any point! Useful details include: use cases, relevant labels, desired outcomes, and any accompanying screenshots.

As a member of the GitHub community, your participation is essential. While we can't promise that every suggestion will be implemented, we want to emphasize that your feedback is instrumental in guiding our decisions and priorities.

Thank you once again for your contribution to making GitHub even better! We're grateful for your ongoing support and collaboration in shaping the future of our platform. ⭐