You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: content/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/troubleshooting-required-status-checks.md
+68Lines changed: 68 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -38,11 +38,79 @@ remote: error: Required status check "ci-build" is failing
38
38
39
39
{% ifversion fpt or ghae or ghes or ghec %}
40
40
41
+
## Conflicts between head commit and test merge commit
42
+
41
43
Sometimes, the results of the status checks for the test merge commit and head commit will conflict. If the test merge commit has a status, the test merge commit must pass. Otherwise, the status of the head commit must pass before you can merge the branch. For more information about test merge commits, see "[Pulls](/rest/reference/pulls#get-a-pull-request)."
42
44
43
45
44
46
{% endif %}
45
47
48
+
## Handling skipped but required checks
49
+
50
+
Sometimes a required status check is skipped on pull requests due to path filtering. For example, a Node.JS test will be skipped on a pull request that just fixes a typo in your README file and makes no changes to the JavaScript and TypeScript files in the `scripts` directory.
51
+
52
+
If this check is required and it gets skipped, then the check's status is shown as pending, because it's required. In this situation you won't be able to merge the pull request.
53
+
54
+
### Example
55
+
56
+
In this example you have a workflow that's required to pass.
57
+
58
+
```yaml
59
+
name: ci
60
+
on:
61
+
pull_request:
62
+
paths:
63
+
- 'scripts/**'
64
+
- 'middleware/**'
65
+
jobs:
66
+
build:
67
+
runs-on: ubuntu-latest
68
+
strategy:
69
+
matrix:
70
+
node-version: [12.x, 14.x, 16.x]
71
+
steps:
72
+
- uses: actions/checkout@v2
73
+
- name: Use Node.js ${{ matrix.node-version }}
74
+
uses: actions/setup-node@v2
75
+
with:
76
+
node-version: ${{ matrix.node-version }}
77
+
cache: 'npm'
78
+
- run: npm ci
79
+
- run: npm run build --if-present
80
+
- run: npm test
81
+
```
82
+
83
+
If someone submits a pull request that changes a markdown file in the root of the repository, then the workflow above won't run at all because of the path filtering. As a result you won't be able to merge the pull request. You would see the following status on the pull request:
84
+
85
+
86
+
87
+
You can fix this by creating a generic workflow, with the same name, that will return true in any case similar to the workflow below :
88
+
89
+
```yaml
90
+
name: ci
91
+
on:
92
+
pull_request:
93
+
paths-ignore:
94
+
- 'scripts/**'
95
+
- 'middleware/**'
96
+
jobs:
97
+
build:
98
+
runs-on: ubuntu-latest
99
+
steps:
100
+
- run: 'echo "No build required" '
101
+
```
102
+
Now the checks will always pass whenever someone sends a pull request that doesn't change the files listed under `paths` in the first workflow.
103
+
104
+
105
+
106
+
{% note %}
107
+
108
+
**Notes:**
109
+
* Make sure that the `name` key and required job name in both the workflow files are the same. For more information, see "[Workflow syntax for {% data variables.product.prodname_actions %}](/actions/reference/workflow-syntax-for-github-actions)".
110
+
* The example above uses {% data variables.product.prodname_actions %} but this workaround is also applicable to other CI/CD providers that integrate with {% data variables.product.company_short %}.
111
+
112
+
{% endnote %}
113
+
46
114
It's also possible for a protected branch to require a status check from a specific {% data variables.product.prodname_github_app %}. If you see a message similar to the following, then you should verify that the check listed in the merge box was set by the expected app.
0 commit comments