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

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

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

注: Git リベースを使用してブランチをベースブランチと同じ最新状態にすることもできます。詳しくは、「Git リベースについて」を参照してください。

必須ステータスチェックにすべてパスするまでは、ローカルでの変更を保護されたブランチにプッシュすることはできません。その代わりに、以下のようなエラーメッセージが返されます。

remote: error: GH006: Protected branch update failed for refs/heads/main.
remote: error: Required status check "ci-build" is failing

注: 必須状態チェックに合格した最新の pull request は、ローカルでマージされた後で、保護されたブランチにプッシュできます。これはマージコミット自体でステータスチェックを実行せずに行えます。

head コミットとテストマージコミットの間の競合

テストマージコミットと head コミットのステータスチェックの結果が競合する場合があります。テストマージコミットにステータスがある場合、そのテストマージコミットは必ずパスする必要があります。それ以外の場合、ヘッドコミットのステータスは、ブランチをマージする前にパスする必要があります。テストマージコミットの詳細については、「Pulls」を参照してください。

スキップされた必須チェックの処理

注: パスのフィルター処理、ブランチのフィルター処理、またはコミットメッセージのためにワークフローがスキップされた場合、そのワークフローに関連付けられているチェックは "保留中" 状態のままになります。これらのチェックを成功させる必要がある pull request は、マージが禁止されます。

ワークフロー内のジョブが条件付きでスキップされた場合、状態は "成功" として報告されます。詳細については、「ワークフロー実行をスキップする」および「条件を使用してジョブの実行を制御する」を参照してください。

例

次の例で示すのは、build ジョブの完了状態が "成功" であることが必要なワークフローです。ただし、pull request が scripts ディレクトリのどのファイルも変更しないと、このワークフローはスキップされます。

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

パスのフィルター処理のために、リポジトリのルートのファイルのみを変更する pull request は、このワークフローをトリガーせず、マージがブロックされます。 pull request には、"状態の報告を待機しています" と表示されます。

これを修正するには、同じ名前の汎用ワークフローを作成して、次のワークフローのようにどのケースでも true を返すようにします。

name: ci
on:
  pull_request:
    paths-ignore:
      - 'scripts/**'
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - run: 'echo "No build required"'

これで、誰かが送った pull request が最初のワークフローの paths 内のファイルを変更しないときも常にチェックに合格します。

注:

両方のワークフローファイルの name キーと必須ジョブ名を同じにしてください。詳しくは、「GitHub Actions のワークフロー構文」をご覧ください。
上記の例では GitHub Actions が使用されていますが、この対処方法は、GitHub と統合されている他の CI/CD プロバイダーにも適用できます。

予期しないソースからの必要な状態チェック

保護されたブランチで、特定の GitHub App の状態チェックを必須にすることもできます。次のようなメッセージが表示された場合は、マージボックスに一覧表示されているチェックが、想定されるアプリによって設定されたことを確認する必要があります。

Required status check "build" was not set by the expected GitHub App.

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

この記事の内容

head コミットとテスト マージ コミットの間の競合

スキップされた必須チェックの処理

例

予期しないソースからの必要な状態チェック

head コミットとテストマージコミットの間の競合