本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

# 排查 webhook 的问题
<a name="action-runner-troubleshoot-webhook"></a>

**问题：**您在中设置的 webhook [教程：配置 CodeBuild-hosted GitHub 操作运行器](action-runner.md) 无法运行或您的工作流程任务处于挂起状态。 GitHub

**可能的原因：**
+ 您的 webhook **工作流程作业**事件可能无法触发构建。检查**响应**日志以查看响应或错误消息。
+ 由于标签配置，您的作业分配给了不正确的运行程序代理。当单个工作流程运行中一个作业的标签少于另一个作业时，就会出现此问题。例如，如果您在同一个工作流程运行中具有两个带有以下标签的作业：
  + **作业 1**：`codebuild-myProject-${{ github.run_id }}-${{ github.run_attempt }}`
  + **作业 2**：`codebuild-myProject-${{ github.run_id }}-${{ github.run_attempt }}`、`instance-size:medium`

  路由自托管的 Act GitHub ions 任务时， GitHub 会将任务路由到具有所有任务指定标签的任何运行器。此行为意味着为**作业 1** 或**作业 2** 创建的运行程序可以承担**作业 1**，但是由于**作业 2** 有附加标签，因此只能由为**作业 2** 创建的运行程序承担该作业。如果为**作业 2** 创建的运行程序承担了**作业 1**，则**作业 2** 将卡住，因为**作业 1** 运行程序没有 `instance-size:medium` 标签。

**推荐的解决方案：**

在同一个工作流程运行中创建多个作业时，请为每个作业使用相同数量的标签覆盖，或者为每个作业分配一个自定义标签，例如 `job1` 或 `job2`。

为每项任务分配自己独特的自定义标签是最可靠的选择。它确保任何作业的标签集都不是另一个任务的子集。当每个作业都带有其他作业没有的标签时，无论每个作业使用多少其他替代项，都只将每个作业与为其创建的运行器进行 GitHub 匹配。在以下工作流程中，每个作业都有唯一的标签（`job1`和`job2`）。尽管**作业 2 ** 有额外的`instance-size:medium`替代，但**作业 1 ** 无法再与为作**业 2 创建的运行器相匹配**，因此这两个任务都不会卡住：

```
name: Hello World
on: [push]
jobs:
  job1:
    runs-on:
      - codebuild-myProject-${{ github.run_id }}-${{ github.run_attempt }}
      - job1
    steps:
      - run: echo "Hello from Job 1!"
  job2:
    runs-on:
      - codebuild-myProject-${{ github.run_id }}-${{ github.run_attempt }}
      - instance-size:medium
      - job2
    steps:
      - run: echo "Hello from Job 2!"
```

如果错误仍然存在，请按照以下说明调试问题。

1. 在处打开 GitHub 控制台`https://github.com/{{user-name}}/{{repository-name}}/settings/hooks`以查看存储库的 webhook 设置。在此页面上，您将看到为您的存储库创建的 webhook。

1. 选择 “**编辑” ** 并确认启用 Webhook 以传送**工作流任务**事件。  
![工作流作业事件已在您的 webhook 中启用。](https://docs.aws.amazon.com/zh_cn/codebuild/latest/userguide/images/github-actions-workflow-jobs.png)

1.  导航至**最近传输**选项卡，找到相应的 `workflow_job.queued` 事件，然后展开该事件。

1.  查看 P ** ayload 中的**标签**字段**，确保其符合预期。

1.  最后，查看 ** “**响应” 选项卡，因为其中包含从返回的响应或错误消息 CodeBuild。  
![返回的响应或错误消息 CodeBuild。](https://docs.aws.amazon.com/zh_cn/codebuild/latest/userguide/images/github-actions-workflow-jobs-response.png)

1.  或者，您可以使用的 API 调试 webhook 故障。 GitHub您可以使用[列出存储库 webhook 的传输](https://docs.github.com/en/rest/repos/webhooks?apiVersion=2022-11-28#list-deliveries-for-a-repository-webhook) API 来查看 webhook 的近期传输：

   ```
   gh api \
     -H "Accept: application/vnd.github+json" \
     -H "X-GitHub-Api-Version: 2022-11-28" \
     /repos/{{owner}}/{{repo}}/hooks/{{hook-id}}/deliveries
   ```

    找到你要调试的 webhook 交付并记下交付 ID 后，你可以使用 “[获取仓库交付” webhook API ](https://docs.github.com/en/rest/repos/webhooks?apiVersion=2022-11-28#get-a-delivery-for-a-repository-webhook)。 CodeBuild可以在以下`response`部分中找到对 webhook 交付负载的回应：

   ```
   gh api \
     -H "Accept: application/vnd.github+json" \
     -H "X-GitHub-Api-Version: 2022-11-28" \
     /repos/{{owner}}/{{repo}}/hooks/{{hook-id}}/deliveries/{{delivery-id}}
   ```

**问题：**在[部署获得批准 CodeBuild 之前，启用了部署保护](https://docs.github.com/en/actions/managing-workflow-runs-and-deployments/managing-deployments/reviewing-deployments)规则的 GitHub 操作会触发内部构建。

**可能的原因：** CodeBuild 获取与 Act GitHub ions 任务相关的部署和环境（如果存在），以验证部署是否获得批准。如果 CodeBuild 无法获取部署或环境，则可能会过早触发 CodeBuild 构建。

**推荐的解决方案：**验证与您的 CodeBuild 项目关联的凭据是否具有内部部署和操作的读取权限 GitHub。