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

必要な状態チェックのトラブルシューティングを行い、よくあるエラーを解決し、保護されたブランチへのマージやプッシュの制限を解除します。

必要な状態チェックが、保護されたブランチへのマージまたはプッシュをブロックする場合は、これらのチェックを使用します。 「[状態の確認](/ja/enterprise-server@3.21/pull-requests/reference/status-checks)」を参照してください。

* 過去 7 日間に、選択したリポジトリで必要な状態チェックが正常に完了している必要があります。
* チェックとコミット状態の名前が同じ場合、その名前が必須とされる際には、両方が条件を満たしている必要があります。 「[チェック用 REST API エンドポイント](/ja/enterprise-server@3.21/rest/checks)」を参照してください。
* ブランチ保護でブランチが最新の状態であることが必要な場合は、ベース ブランチを自分のブランチにマージするか、ベース ブランチ上に自分のブランチをリベースします。 「[保護されたブランチについて](/ja/enterprise-server@3.21/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches#require-status-checks-before-merging)」と「[Git リベースについて](/ja/enterprise-server@3.21/get-started/using-git/about-git-rebase)」を参照してください。

必要な状態チェックに合格しなかった場合、保護されたブランチにプッシュすると、次のようなエラーが返されます。

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

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

## 必要なチェックが最新のコミット SHA に対して成功する必要があります

必要なチェックが引き続きプル要求をブロックしている場合は、次を確認します。

* 必要なチェックは、最新のコミット SHA に対して合格している必要があります。 以前のコミットからのチェックは、要件を満たしていません。
* 成功したチェックの状態は、 `success`、 `skipped`、および `neutral`。 「[状態の確認](/ja/enterprise-server@3.21/pull-requests/reference/status-checks)」を参照してください。

## ヘッドコミットとテストマージコミットの間の競合

プル リクエストの状態チェック ボックスを使用して、どのコミットが合格する必要があるかを特定します。

| 状態チェックソース                  | 通過する必要があるもの | 表示される内容                               |
| -------------------------- | ----------- | ------------------------------------- |
| テスト マージ コミットには状態があります      | テストマージコミット  | `Showing checks for the merge commit` |
| テスト用のマージ コミットにはステータスがありません | ヘッド コミット    | 最新のヘッド コミットを確認します                     |

「[Pull request 用 REST API エンドポイント](/ja/enterprise-server@3.21/rest/pulls/pulls#get-a-pull-request)」を参照してください。

## 一部のワークフロージョブからのチェックが評価されない

GitHub Actionsワークフロー実行では、プル要求のチェック セクションに表示されないチェックをレポートしたり、ブランチ ルールセットで必要な状態チェックを満たしたりできます。 ワークフロー ジョブによって作成されたチェックをプル要求に対して評価するには、次のいずれかのイベントによってワークフローの実行をトリガーする必要があります。

* `push`
* `pull_request`
* `pull_request_review`
* `pull_request_target`
* `deployment`
* `deployment_status`

たとえば、プル要求のヘッド ブランチで `workflow_dispatch` によってワークフローがトリガーされた場合、そのジョブによって報告されたチェックはプル要求のチェック セクションには表示されません。 ヘッドコミットに対するチェックが成功していても、ブランチルールセットで必須のステータスチェックを満たすことにはなりません。

ワークフローの実行をトリガーしたイベントを確認します。 ワークフローで別のイベントが使用されている場合は、その `on` 構成を更新して、ワークフローに適したイベント ( `pull_request` など) を使用します。 「[ワークフローをトリガーするイベント](/ja/enterprise-server@3.21/actions/reference/workflows-and-actions/events-that-trigger-workflows)」を参照してください。

この制限は、ワークフロー ジョブによって作成されたチェックにのみ適用され、外部 GitHub Appによって作成されたチェックには適用されません。

マージ キューには、個別の `merge_group` イベントが必要です。
[
GitHub Actionsとマージ キューを使用した状態チェックを](#status-checks-with-github-actions-and-a-merge-queue)参照してください。

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

| 原因                                                                                                                                                                                                                                                                                                                                                                                                                                       | Result                                  | 修正または確認する方法                                                                                                                                                                                          |
| ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| [パス のフィルター処理、分岐のフィルター処理](/ja/enterprise-server@3.21/actions/reference/workflows-and-actions/workflow-syntax#onpushpull_requestpull_request_targetpathspaths-ignore)、[](/ja/enterprise-server@3.21/actions/reference/workflows-and-actions/workflow-syntax#onpull_requestpull_request_targetbranchesbranches-ignore)または[コミット メッセージ](/ja/enterprise-server@3.21/actions/how-tos/manage-workflow-runs/skip-workflow-runs)によってワークフローがスキップされる | 関連付けられているチェックは "保留中" 状態のままで、マージをブロックします | スキップできるワークフローを必要としないようにします。                                                                                                                                                                          |
| 条件によってジョブがスキップされる                                                                                                                                                                                                                                                                                                                                                                                                                        | ジョブが「成功」と報告する                           | 「[条件を使用してジョブの実行を制御する](/ja/enterprise-server@3.21/actions/how-tos/write-workflows/choose-when-workflows-run/control-jobs-with-conditions)」を参照してください。                                                  |
| ジョブは失敗したジョブに依存する                                                                                                                                                                                                                                                                                                                                                                                                                         | 依存ジョブはスキップされ、マージがブロックされない場合があります        | 他のジョブに依存する必要なチェックには、`always()`で`needs`を使用します。 「[ワークフローでジョブを使用する](/ja/enterprise-server@3.21/actions/how-tos/write-workflows/choose-what-workflows-do/use-jobs#defining-prerequisite-jobs)」を参照してください。 |

マージ前にパスするためにワークフローが必要な場合は、パスまたはブランチ フィルターを使用してワークフローの実行をスキップしないでください。 詳細については、「[ワークフロー実行をスキップする](/ja/enterprise-server@3.21/actions/how-tos/manage-workflow-runs/skip-workflow-runs)」および「[ルールセットで使用できるルール](/ja/enterprise-server@3.21/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/available-rules-for-rulesets#require-workflows-to-pass-before-merging)」を参照してください。

### Example

このワークフローには正常な `build` ジョブが必要ですが、プル要求が `scripts`内のファイルを変更した場合にのみ実行されます。

```yaml
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@v6
    - name: Use Node.js ${{ matrix.node-version }}
      uses: actions/setup-node@v7
      with:
        node-version: ${{ matrix.node-version }}
        cache: 'npm'
    - run: npm ci
    - run: npm run build --if-present
    - run: npm test
```

リポジトリ ルート内のファイルのみを変更するプル要求では、このワークフローはトリガーされません。
`build`が必要な場合、pull request は "状態の報告を待機しています" でブロックされます。

### GitHub Actionsとマージ キューを使用した状態チェック

マージ キューで GitHub Actions チェックが必要な場合は、 `merge_group` イベントを使用してワークフローをトリガーします。

> \[!NOTE]
> リポジトリで GitHub Actions を使用して、リポジトリ内の pull request において必要なチェックを実行する場合、または組織のルールセットを介するワークフローが必要な場合は、追加のトリガーとして `merge_group` イベントを含むようにワークフローを更新する必要があります。 それ以外の場合、マージ キューに pull request を追加しても、ステータス チェックがトリガーされません。 必要な状態チェックが報告されないため、マージは失敗します。 `merge_group` イベントは、`pull_request` および `push` イベントとは異なります。

トリガー構成の例:

```yaml
on:
  pull_request:
  merge_group:
```

「[ワークフローをトリガーするイベント](/ja/enterprise-server@3.21/actions/reference/workflows-and-actions/events-that-trigger-workflows#merge_group)」を参照してください。

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

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

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