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.

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.

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

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

I've created a GitHub Action that wraps the logic of what @danieltroger described in a nicer package. Check it out at https://github.com/wechuli/allcheckspassed. It provides some additional options such as excluding certain checks from the evaluation and choosing what exactly constitutes a passing check (e.g. skipped, neutral). The action also creates a summary of the checks that were evaluated. Additional documentation is on the README.

Ultimately this is only a workaround for a missing feature, the main downside it has is that you need to configure it on its own workflow and it will consume your Actions minutes, I have tried to document this under limitations section. Let me know what you think, if you want some features it doesn't have, please open an issue (or a pr 😉 ).

Just a note that https://github.com/palantir/policy-bot is a great option until github support this. Only real downside is the duplication of conditions between the policies and the conditional jobs imo.

the way I solved this issue is by adding a job like the following to all the workflows.

check-for-successful-tests:
    needs: [test-job-1, test-job-2, test-job-3]
    if: ${{ success() || failure() }}
    steps:
      - name: Check outcomes
        if: ${{ needs.test-job-1.result == 'failure' || needs.test-job-2.result == 'failure' || needs.test-job-3.result == 'failure' }}
        run: exit 1

and a dummy workflow with the same job name that runs exit 0. I marked check-for-successful-tests as required. this way i'm sure that the job runs 100 percent of the time and also if a required check is failing it blocks the merge.

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.

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

Duplicate of #44490 ?