Allow required checks to pass/skip, not fail, when using path filtering

[gustavovalverde]

Select Topic Area

Product Feedback

Body

As a repository starts to grow and depends more and more on GitHub Actions for CI, it also becomes more necessary to make workflows required.

Not being able to skip a required action, if it was filtered by paths rules, creates a burden for developers/DevOps maintaining extra files in sync with the original workflow.

For example, any coding language with a CI pipeline will evaluate if any file having the specified language in it was changed, and if not, it will skip the workflow:

name: CI

on:
  pull_request:
    paths:
      - '**/*.py'

The offered workaround in the official documentation is to create another workflow, ignoring the path and including each step with a script to return the correct exit code: https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/troubleshooting-required-status-checks#handling-skipped-but-required-checks

This is far from optimal, as it create N + 1 files for each required workflow, and it requires to create each step in the extra workflow. While keeping them in sync if any extra step is added in the original workflow.

This also doubles the checks in the PR UI, and does not allow to understand which workflows were run and which were not.

This workflow directory is an example of the burden created by this workaround https://github.com/ZcashFoundation/zebra/tree/main/.github/workflows and any PR will show like all workflows are run, but this are just the patch workflows which are running.

Hopefully we can have an option in the repository to specify if workflows can be skipped (by the paths filters) even if the workflow is required.

Note: This discussion refers to the same issue, but it was marked as answered with a different workaround which won't work on repositories like ours, as it creates extra steps, dependencies and complexity: https://github.com/orgs/community/discussions/26857#discussioncomment-3253667

[elyobo]

Another approach might be to allow similar path filtering on the required tests.

[MarcDufresne]

We're seeing the same issue in our monorepo. We have over 20 services and libraries, each with their own workflows, and a collection of reusable workflows (for tests, Docker builds, deployments).

Initially, we were using the native path filtering to only run the workflows of changed services, but as we discovered GitHub Actions doesn't support path filters when using required checks, as each required check will sit there and not be marked as skipped, thus blocking the PR from merging. Additionally, we are also using the merge queue, so required checks are absolutely necessary.

We found an alternative using dorny/paths-filter. However, since we need to run the check ourselves then we incur 1 minute of billable time per service and library. Currently this costs us 23 minutes of billable time, on each commit in a PR or our main branch, just to check if we should run the actual workflows or not. This is frankly unacceptable that we must pay for this very basic feature. A feature that was supported by other CI/CD tools we used, like Azure DevOps.

We've also tried to create a "master" workflow that would run a single path filter check, and execute each workflow service as a reusable workflow depending on the result of the path filter check. Thus costing us only 1 minute per commit instead of 23. However, we've now reached another GitHub Actions limit, where a workflow cannot reference more than 20 reusable workflows.

I really hope that GitHub fixes this very basic use case of not supporting path filters and required checks together.

[petermetz]

^^ The exact same issue here. Our mono-repo has 60+ packages, each with their own test suites.

I really hope that GitHub fixes this very basic use case of not supporting path filters and required checks together.

Plus one!

[frickerj]

also encountering this exact same problem - absurb that there isn't a solution for this

[ManavDia]

Also ran into this issue today +1 for a feature/fix from Github to address this issue.

[antoniogamizbadger]

Same problem, surprising this is not suopported. More discussions -> https://github.com/orgs/community/discussions/13690