Branch protections when actions use paths-ignore

[kevinm416]

Select Topic Area

Question

Body

I've got a repo with a frontend build and a server build. Each only runs when files in the appropriate folder change via the paths-ignore option in the github workflow files. I'm trying to configure my repo so that merges to master can only happen if whatever checks are triggered have passed.

I don't see an option for doing that though. It looks like I can only set up the branch rule so that a hard-coded list of checks pass. If I put all the checks in the list that need to pass, then a web-only change would never be able to be merged because the server build never runs.

This seems like it would be a common situation. Has anyone figured out how to do this?

[hrishikesh-kocharekar-dev]

Hi Kevin,
Yes, it's a common situation to have multiple checks that need to pass before merging to the master branch. Fortunately, GitHub provides a flexible way to configure branch protection rules to enforce certain requirements.

To achieve what you are describing, you can set up a branch protection rule for the master branch that requires all checks to pass before allowing a merge. Then, you can add multiple status checks for your repository in the settings. These status checks can be configured to only run on certain files or folders by using the "paths-ignore" option in the GitHub workflow files.

Here are the general steps to set up the branch protection rule and status checks:

Go to your repository on GitHub and click on "Settings".
Click on "Branches" on the left-hand side menu.
Under "Branch protection rules", select the master branch and click "Edit".
Check the box next to "Require status checks to pass before merging".
Select the status checks you want to require from the list.
Click "Save changes".
Now, when someone tries to merge changes into the master branch, all the selected status checks will be run. If any of the checks fail, the merge will be blocked until the issues are resolved.

To make sure that your status checks only run on the appropriate files, you can configure the GitHub workflow files in your repository to use the "paths-ignore" option. For example, you could have one workflow file that only runs when changes are made to the frontend files and another workflow file that only runs when changes are made to the server files.

I hope this helps!

[kevinm416]

Hi Hrishikesh, thank you for your reply, However, I already have all the stuff you described set up. Maybe this is a clearer explanation of my issue.

When I configure the checks like this, everyone can merge without the checks completing successfully:

When I configure the checks like this, I can't merge frontend changes, because they do not trigger build-api:

[danielo515]

How do you exclude certain PRs from requiring certain checks?

[fniephaus]

This is probably what you are looking for: https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/troubleshooting-required-status-checks#handling-skipped-but-required-checks

[kevinm416]

Hi Fabio, thanks for the pointer! I actually read that at the time, but didn't really understand what it was suggesting.

What I've done is require a pre-merge check before merging to the main branch, and added that pre-merge check in each build workflow. Previously, the checks were named things like build-api, build-web, etc. By naming them all pre-merge, whichever workflows get triggered, at least one will provide a pre-merge result, and it's ok if multiple provide pre-merge checks.

I think that's what that article is hinting at, but it didn't click for me.

[rob-levy-minimum]

The link in the accepted answer is a 404, but here's an updated link.

[ViacheslavP]

FYI The previous link contained the workaround that doesn't seem to work today: http://web.archive.org/web/20230506221415/https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#onpushpull_requestpull_request_targetpathspaths-ignore

[bojingo]

The content at the link was updated again but only gives an explanation and example of why the PRs get stuck "pending" on an action that was not run due to a path filter, but doesn't fully explain or give an example of a solution! I can infer to use a conditional to skip execution rather than path filter, but how about giving us an example and explanation of a working solution to the problem?

Azure Repos gives ability to set path filter in build validations (roughly equivalent of GitHub Actions workflow branch protection status check). I'd like to know how to accomplish the same capability.