Required actions workflows from branch protections should only be required if run

[daltonv]

If you have branch protections set so that a GitHub Action workflow must be run and pass before you can merge, and this workflow has path filtering in the on: clause then you sometimes can't ever merge because the workflow doesn't run.

This GitHub docs talk about this issue here: https://docs.github.com/en/enterprise-cloud@latest/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/troubleshooting-required-status-checks#handling-skipped-but-required-checks

There is a workaround suggested in the doc article, but it involves making a "dummy" workflow of the same name of the required workflow. This dummy workflow always passes and is triggered by the inverse path filtering of the required workflow.

This isn't the best solution in my mind because:

• devs now see two workflows with the same name in the Actions tab of a repo. That's confusing and too much clutter
• The "dummy" workflow runs along with the required workflow sometimes. For example if the required workflow only runs when *.c files are changed, the "dummy" workflow and the required workflow run if BOTH *.c files and non *.c files are changed.

Instead it should be changed so local workflows are only required if they run in the first place.

[ethomson]

Thanks @daltonv. I agree that this is not the ideal solution. I'll talk with the team that owns branch protection to give them your feedback. I'll also talk to the docs team to suggest some improvements for this article in the meantime.

Thanks again for taking the time to leave feedback.

[gustavovalverde]

Hi @ethomson, while looking for more info I just realized I duplicated this discussion. But I'm sharing mine to add more context on other scenarios which make the actual workaround very messy https://github.com/orgs/community/discussions/44490#discussion-4761945

I'm specifically bringing this link out, just so you (and others) can realize how much burden the recommended workaround from the documentation adds to the pipelines: https://github.com/ZcashFoundation/zebra/tree/main/.github/workflows

[lhriley]

This should be a generalized change as it affects users who don't use GitHub Actions, but instead have third party CI/CD integrations triggered via webhooks.

The option should simply be Require triggered checks to pass rather than specifying a list of checks as being required.

[kousu]

This is the behaviour I expect too! And having to explicitly manage the checks to pass in the GUI is redundant and bug-prone. I want to manage everything by code.

[joshuat]

Just chiming in and it's kind of shocking there's no way to do this - if a task runs I expect it to either pass or at least have the option of blocking merges without having to itemize every task.

Having to itemize them creates a security gap and as mentioned above is problematic when dealing with conditional tasks.

[p0fi]

This is the only sane behavior any human could think of. How come it's implemented otherwise? Who would want to specify those checks ahead of time in the repo settings? Why? Just why? This makes this feature utterly useless I believe.

[natethelen]

Agreed. I can't believe this isn't the first thing that was implemented around requiring github actions to pass in branch protections. There 100% should be a checkbox that allows you to require any triggered workflow to pass.

[connorstorer-kbxcom]

THANK YOU ALL FOR VALIDATING MY THOUGHTS! I've been scratching my head on why this isn't possible - just came across this. Frustrating - but not surprising.

[Scotchester]

See also the most active discussion in ye olde GitHub Community Forum on this topic: https://github.community/t/feature-request-conditional-required-checks/16761

[steinybot]

Link seems to be broken

[antoniogamizdelgado]

https://github.com/orgs/community/discussions/44490

[antoniogamizdelgado]

I think is either the same one or one equivalent.

[solarmosaic-kflorence]

See also https://github.community/t/feature-request-required-checks-conditioned-on-path/2042

[andrelaszlo]

Where did this page go? I've found it in a lot of places, but now it just redirects to the GitHub Community landing page.

[betaorbust]

Ran into it as well. Having something like this would also let us implement more straightforward skipping. For instance, I don't need to to spend the time running all our test, visual regressions, etc. on a PR from an internal bot that edits changelogs, but I absolutely want those to be required checks for us humans so we can use really helpful things like auto-merging, etc.

[joegaudet]

Very much want this, we spend piles of cash on GitHub because of this shortcoming.

[DGuhr]

+1. We have the same problem over at Keycloak: Multiple workflows / jobs are running for e.g. a simple typo in our documentation, or a bump in npm dependencies. Would be very nice to have better support than the dummy workflow approach.

[kimyu-ng]

Running into similar problem when using conditional workflow via circle-ci.

It should not be waiting infinitely if the workflow doesn't run at all

[KevinDukelow5]

+1, it's surprising that GitHub and disappointing that GitHub doesn't fully support a code first approach for the definition of requirements. The dummy workaround is hacky to say the least.

[dodomood]

+1
can we plz haz?

[courentin]

+1
The workaround does not work with commit message skipping (ie. [skip ci] in commit message) as the dummy workflow is never run because of the [skip ci].

[OneCyrus]

this is a real pain. any update on this? @ethomson

[joegaudet]

Hard not to see this as a cash grab, we've been asking for it for 3 years now, the only way to safely protect branches in this scenario is to run all checks always.

[annabkr]

Came here to add to the chorus of programmers asking for help with this sad trombone UX.

[andrelaszlo]

I got the "dummy workflow workaround" working but it broke after about a week. I don't know if it was some internal Github change or if my setup is just fragile, but the whole situation is pretty disappointing nonetheless.

[mbarr-hrp]

We've actually used https://github.com/dorny/paths-filter to create conditional actions, based on paths, that still succeed in the end.

Workflow runs, it decides if it needs to do the work, and then passes/fails based on the work.

If it doesn't need to do the work, it skips the conditional job, and passes.

[hankhsu1996]

I tried the path filter action approach, and it’s been incredibly frustrating. The configuration goes like this:

1. Don’t set any path filter in the trigger condition.
2. Add a job to handle path filtering using an action like this one: https://github.com/tj-actions/changed-files.
3. Use the output of the path filter in the actual job by specifying the if condition to force the job to pass.

Initially, this seemed like a reasonable solution, but it completely breaks down when you have even a slightly complex setup with job dependencies.

For example, my CI has a build phase and a test phase, where the test phase has a matrix of runtime arguments. All these test jobs with different matrix values are marked as "required checks to pass."

The issue arises when the file changes aren’t related to this CI. In such cases, I need to skip the build and test phases. If I use if in the build phase based on the path filter output, the build is skipped, but the test jobs don’t trigger. If I use if in the test jobs, then none of the matrix entries are triggered. Either way, the result is the same: the PR merge is blocked indefinitely because the required jobs are never run.

To hack around this, you can’t rely on path filtering in the workflow or job scope. Instead, you have to move the path filtering logic into steps. You check the output of the path filter job as a global variable, and in every job, the first step checks this variable. If the job needs to be skipped, you force a pass in the step itself, not in the job’s if condition. This ensures that all jobs, including matrix jobs, are triggered and avoid blocking the workflow.

This approach is far more complicated than it should be. Something as basic as skipping jobs based on file changes shouldn’t require this level of convoluted hacking. It’s frustrating and feels like an overengineered solution for what should be a straightforward problem.

[echeran]

Have you tried https://github.com/poseidon/wait-for-status-checks ? It was mentioned above. It works really well for plugging the hole that Github has not yet fixed. I don't know why it isn't more upvoted and commented on in this thread.

[antoniogamizdelgado]

Because you need to spend more minutes of Github Actions. In expensive workflow runs like the ones using MacOS, the cost can add up pretty quickly.

[echeran]

I see. Tradeoffs indeed. I respect that situation & constraints. For my situation, it happens to be that the value of the pros outweigh the cons enough to use that action. (Of course, it would be nice in the future for the 2 different features of Github Actions to natively play nice together so that we wouldn't have to choose among workarounds.)

[hankhsu1996]

@echeran Thank you, I'll try it

[tjzel]

Hey, are any updates on this? Is the GitHub team planning to implement this feature?

[wAuner]

Since 2022, this glaring issue has remained unresolved and unimplemented. This is not a feature request; it’s a genuine problem. While I was initially pleased with the migration to GitHub, we’ve encountered numerous frustrating obstacles that defy explanation. This issue is one of them. Others include the lack of support for proper required reviews (such as supporting only OR in codeowners files, extremely limited path filters.
I’m constantly forced to find obscure workarounds or rely on third-party actions (which is very problematic in enterprise environments) for even the most basic tasks.

[sacrio23]

If you have branch protections set so that a GitHub Action workflow must be run and pass before you can merge, and this workflow has path filtering in the on: clause then you sometimes can't ever merge because the workflow doesn't run.

This GitHub docs talk about this issue here: https://docs.github.com/en/enterprise-cloud@latest/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/troubleshooting-required-status-checks#handling-skipped-but-required-checks

There is a workaround suggested in the doc article, but it involves making a "dummy" workflow of the same name of the required workflow. This dummy workflow always passes and is triggered by the inverse path filtering of the required workflow.

This isn't the best solution in my mind because:

devs now see two workflows with the same name in the Actions tab of a repo. That's confusing and too much clutter
The "dummy" workflow runs along with the required workflow sometimes. For example if the required workflow only runs when *.c files are changed, the "dummy" workflow and the required descargar minecraft 1.17 para android apk workflow run if BOTH *.c files and non *.c files are changed.
Instead it should be changed so local workflows are only required if they run in the first place.

Agreed requiring a workflow that never runs due to path filtering is counterproductive. GitHub should make required checks conditional on whether the workflow actually triggers, instead of forcing dummy workflows that clutter the Actions list.

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

[nemanjaglumac]

You are absolutely right™

👍

[jackmtpt]

This is going to be a serious issue for us trying to migrate from Azure DevOps to GitHub. We have several monorepos in ADO with various pipelines that are triggered or not based on what files changed (via build validation policies) and without the ability for github to only care about the checks that are relevant we'll have to implement a lot of hacky shit to make it work, or more likely just not migrate.

[jackmtpt]

So it looks like in the specific case of Azure DevOps, this does now work as desired. The Azure Pipelines integration sets the status to 'skipped' which is counted as success-like as far as the github ruleset status checks go:

I tested this before and it used to be the case that the PR (which only modified a file from Service A) was blocked from merging, but the above PR was able to be merged successfully as desired.

Both the A and B pipelines use these triggers (obviously with the paths changed for B):

trigger:
  branches:
    include:
    - main
  paths:
    include:
    - service-a/**
    - service-a.yml

pr:
  branches:
    include:
    - main
  paths:
    include:
    - service-a/**
    - service-a.yml

[Magnuti]

Duplicate of #44490 ?

[nemanjaglumac]

Given that this thread is from 2022, and the one you linked is from 2023, it's the other way around. But yeah - they are both requests for the sane CI functionality that GitHub is simply ignoring.

[ruben-b-ispnext]

It's sad to see GitHub give so little about it's users and leaving us completely in the dark. This has been a basic feature in Azure DevOps since 2017.

[joshuat]

Well I guess this thread is getting locked - thanks for that, spammers.

For the record this is a feature I almost do not comprehend is missing and is routinely one of the reasons I look at moving us away from GH Actions to an external CI/CD provider.

[lra]

1. just report the spam
2. point to this thread when they are asking for feedback about github action (I get the survey regularly)