同じ名前のチェックとステータスがあり、その名前をステータスチェック必須とするようにした場合、チェックとステータスはどちらも必須になります。 詳しい情報については、「チェック」を参照してください。
ステータスチェック必須を有効にした後、マージする前にブランチをベースブランチに対して最新にする必要がある場合があります。 これによって、ブランチがベースブランチからの最新のコードでテストされたことが保証されます。 ブランチが古い場合、ベースブランチをブランチにマージする必要があります。 詳しい情報については保護されたブランチについてを参照してください。
注釈: Git リベースを使用してブランチをベースブランチに対して最新にすることもできます。 詳しい情報については、「Git リベースについて」を参照してください。
必須ステータスチェックにすべてパスするまでは、ローカルでの変更を保護されたブランチにプッシュすることはできません。 その代わりに、以下のようなエラーメッセージが返されます.
remote: error: GH006: Protected branch update failed for refs/heads/main.
remote: error: Required status check "ci-build" is failing
注釈: 最新で必須のステータスチェックをパスしたプルリクエストは、ローカルでマージしてから保護されたブランチにプッシュできます。 これはマージコミット自体でステータスチェックを実行せずに行えます。
Conflicts between head commit and test merge commit
テストマージコミットと head コミットのステータスチェックの結果が競合する場合があります。 テストマージコミットにステータスがある場合、そのテストマージコミットは必ずパスする必要があります。 それ以外の場合、ヘッドコミットのステータスは、ブランチをマージする前にパスする必要があります。 テストマージコミットに関する詳しい情報については、「プル」を参照してください。
Handling skipped but required checks
Note: If a workflow is skipped due to path filtering, branch filtering or a commit message, then checks associated with that workflow will remain in a "Pending" state. A pull request that requires those checks to be successful will be blocked from merging.
If a job in a workflow is skipped due to a conditional, it will report its status as "Success". For more information see Skipping workflow runs and Using conditions to control job execution.
サンプル
The following example shows a workflow that requires a "Successful" completion status for the build
job, but the workflow will be skipped if the pull request does not change any files in the scripts
directory.
name: ci
on:
pull_request:
paths:
- 'scripts/**'
jobs:
build:
runs-on: ubuntu-latest
strategy:
matrix:
node-version: [12.x, 14.x, 16.x]
steps:
- uses: actions/checkout@v3
- name: Use Node.js ${{ matrix.node-version }}
uses: actions/setup-node@v3
with:
node-version: ${{ matrix.node-version }}
cache: 'npm'
- run: npm ci
- run: npm run build --if-present
- run: npm test
Due to path filtering, a pull request that only changes a file in the root of the repository will not trigger this workflow and is blocked from merging. You would see the following status on the pull request:
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 :
name: ci
on:
pull_request:
paths-ignore:
- 'scripts/**'
- 'middleware/**'
jobs:
build:
runs-on: ubuntu-latest
steps:
- run: 'echo "No build required" '
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.
ノート:
- 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 GitHub Actions". - The example above uses GitHub Actions but this workaround is also applicable to other CI/CD providers that integrate with GitHub.
It's also possible for a protected branch to require a status check from a specific 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.
Required status check "build" was not set by the expected GitHub App.