Feature request: Expression-based filtering of workflow triggers

[daltonclaybrook]

Why are you starting this discussion?

Product Feedback

What GitHub Actions topic or product is this about?

Workflow Configuration

Discussion Details

Hey folks, I’d like to propose an enhancement to how workflow triggers can be filtered in GitHub Actions.

Currently, workflows are triggered by events such as pull_request, push, and workflow_dispatch. Some events support activity types that allow partial filtering. For example:

on:
  pull_request:
    types: [edited]

This ensures the workflow runs only when a pull request is edited (e.g., title, description, or base branch changes), and not for other activities like new commits.

However, this filtering is not granular enough in some cases.

The Problem

The edited activity type is triggered for multiple distinct changes:

• Title updates
• Description updates
• Base branch changes

There is currently no way to distinguish between these at the workflow trigger level.

For example, suppose I want a workflow to run only when the base branch changes, but not when the title or description changes. Today, the only workaround is to add if conditions to every job in the workflow to manually inspect github.event and skip execution when the condition doesn’t match.

This creates several issues:

1. Checks are still re-evaluated — Even if every job is skipped, GitHub still treats the workflow as having run. This can clear previously passing checks, blocking merges unexpectedly.
2. Skipped checks are treated as passing — In some cases, this can create unsafe states where a previously failing check is effectively bypassed because a skipped check is considered successful. In some cases, this can create unsafe states where a previously failing check is effectively bypassed because a skipped check is considered successful.
3. Unnecessary workflow executions — The workflow still initializes and reports status, even though no meaningful work should occur. The workflow still initializes and reports status, even though no meaningful work should occur.

In short, we can skip jobs, but we cannot truly prevent the workflow from running.

Proposed Enhancement

I’m proposing support for expression-based filtering at the workflow level, similar to how if: works on jobs and steps.

For example:

on:
  pull_request:
    types: [edited]

if: ${{ github.event.changes.base != null }}

With this feature:

• The workflow would receive the edited event.
• The expression would be evaluated.
• If the condition is false, the workflow would be completely skipped.
• No checks would change state.
• No “skipped” jobs would appear.

This would allow developers to use the github context (and other available variables) to precisely control when workflows truly execute, without side effects on check status.

Would love to hear thoughts from the Actions team and others who may have run into similar issues.

[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. ⭐