Skip to main content
ドキュメントには� �繁に更新が� えられ、その都度公開されています。本ページの翻訳はま� 未完成な部分があることをご了承く� さい。最新の情� �については、英語のドキュメンテーションをご参照く� さい。本ページの翻訳に問題がある� �合はこちらまでご連絡く� さい。

このバージョンの GitHub Enterprise はこの日付をもって終了となりました: 2022-06-03. 重大なセキュリティの問題に対してであっても、パッチリリースは作成されません。 パフォーマンスの向上、セキュリティの改善、新機能のためには、最新バージョンのGitHub Enterpriseにアップグレードしてく� さい。 アップグレードに関する支援については、GitHub Enterprise supportに連絡してく� さい。

必� �ステータスチェックのトラブルシューティング

ステータスチェック必� �を使用して、一般的なエラーを調べ、問題を解決できます。

保護されたブランチは、GitHub Free及びOrganizationのGitHub Freeのパブリックリポジトリ、GitHub Pro、GitHub Team、GitHub Enterprise Cloud、GitHub Enterprise Serverのパブリック及びプライベートリポジトリで利用できます。

同じ名前のチェックとステータスがあり、その名前をステータスチェック必� �とするようにした� �合、チェックとステータスはどちらも必� �になります。 詳しい情� �については、「チェック」を参照してく� さい。

ステータスチェック必� �を有効にした後、マージする前にブランチをベースブランチに対して最新にする必要がある� �合があります。 これによって、ブランチがベースブランチからの最新のコードでテストされたことが保証されます。 ブランチが古い� �合、ベースブランチをブランチにマージする必要があります。 詳しい情� �については保護されたブランチについてを参照してく� さい。

注釈: 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@v2
    - name: Use Node.js ${{ matrix.node-version }}
      uses: actions/setup-node@v2
      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:

Required check skipped but shown as pending

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.

Check skipped but passes due to generic 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.