企业 GitHub Actions 故障排除

在 GitHub Enterprise Server 上使用 GitHub Actions 时的常见问题疑难解答。

谁可以使用此功能？

Site administrators can troubleshoot GitHub Actions issues and modify GitHub Enterprise Server configurations.

本文内容

检查 GitHub Actions 的运行状况

可以使用 ghe-actions-check 命令行实用工具检查 你的 GitHub Enterprise Server 实例 上 GitHub Actions 的运行状况。 有关详细信息，请参阅 命令行实用程序 和 访问管理 shell (SSH)。

使用 GitHub Enterprise Server 自签名证书时配置自托管的运行器

我们强烈建议您在 GitHub Enterprise Server 上配置 TLS，并有信任的机构签名的证书。 虽然自签名证书可以工作，但自托管的运行器需要额外的配置，不推荐用于生产环境。 有关详细信息，请参阅“配置 TLS”。

在运行器上安装证书

为使自托管的运行器使用自签名证书连接到 GitHub Enterprise Server，您必须在运行器上安装证书以增强连接安全。

有关安装证书所需的步骤，请参阅运行器操作系统的文件。

配置 Node.JS 使用证书

大多数操作都以 JavaScript 编写并使用 Node.js，这不会使用操作系统证书存储。 要使自托管运行器使用证书，你必须在运行器计算机上设置 NODE_EXTRA_CA_CERTS 环境变量。

可以将环境变量设置为系统环境变量，或在自托管运行器应用程序目录（即运行器软件下载并解包到的目录）中名为 .env 的文件中进行声明。

例如：

NODE_EXTRA_CA_CERTS=/usr/share/ca-certificates/extra/mycertfile.crt

当自托管的运行器应用程序启动时，环境变量将被读取，因此您必须在配置或启动自托管的运行器应用程序之前设置环境变量。 如果您的证书配置更改，您必须重新启动自托管的运行器应用程序。

配置 Docker 容器使用证书

如果您在工作流程中使用 Docker 容器操作或服务容器，则除了设置上述环境变量外，您可能还需要在 Docker 映像中安装证书。

配置 GitHub Actions 的 HTTP 代理设置

如果在 GitHub 上配置了 HTTP 代理服务器：

  • 必须将 .localhost、127.0.0.1 和 ::1 添加到“HTTP 代理排除”**** 列表（以此顺序）。
  • 如果外部存储位置不可路由，则还必须将外部存储 URL 添加到排除列表中。

有关更改代理设置的详细信息，请参阅“配置出站 Web 代理服务器”。

如果未正确配置这些设置，你可能会在设置或更改 GitHub Actions 配置时收到错误，例如 Resource unexpectedly moved to https://IP-ADDRESS。

运行器未使用新主机名连接到 GitHub Enterprise Server

Warning

初始设置后不要更改 GitHub Enterprise Server 的主机名。 更改主机名将会导致意外的行为，甚至包括实例中断和用户安全密钥失效。 如果更改了实例的主机名并遇到问题，请联系GitHub Enterprise 支持或GitHub 高级支持。

如果您在环境中使用新主机名部署 GitHub Enterprise Server，并且旧主机名不再解析到您的实例，则自托管运行器将无法连接到旧主机名，并且不会执行任何作业。

需要更新自承载运行器的配置，以便将新的主机名用于 你的 GitHub Enterprise Server 实例。 每个自托管运行器将需要以下程序之一：

  • 在自托管运行器应用程序目录中，编辑 .runner 和 .credentials 文件以将所有提及的旧主机名均替换为新主机名，然后重启自托管运行器应用程序。
  • 使用 UI 从 GitHub Enterprise Server 移除运行器，并重新添加。 有关详细信息，请参阅 删除自托管的运行器 和 添加自托管的运行器。

作业卡住以及 GitHub Actions 内存和 CPU 限制

GitHub Actions 由在 你的 GitHub Enterprise Server 实例 上运行的多个服务组成。 默认情况下，这些服务使用默认的 CPU 和内存限制设置，大多数情况下都适用。 但是，当 GitHub Actions 用户多时，可能需要调整这些设置。

如果您注意到作业未开始，或者任务进度在 UI 中不更新或改变，可能是达到了 CPU 或内存限制（即使有空闲的运行器）。

1. 在管理控制台中检查整体 CPU 和内存使用情况

访问管理控制台并使用监控仪表板来检查“System Health（系统健康）”下的整体 CPU 和内存图。 有关详细信息，请参阅“关于监视器仪表板”。

如果整体“系统健康”CPU 使用情况接近 100%，或者没有剩余可用内存，你的 GitHub Enterprise Server 实例 就会满负荷运行且需要纵向扩展。 有关详细信息，请参阅“增加 CPU 或内存资源”。

2. 在管理控制台中检查 Nomad Jobs CPU 和内存使用情况

如果总体“系统健康”CPU 和内存使用情况正常，请向下滚动监控仪表板页面到“Nomad Jobs”部分，并查看“CPU 百分比值”和“内存使用情况”图。

这些图表中的每幅图都对应于一项服务。 对于 GitHub Actions 服务，请查询：

  • mps_frontend
  • mps_backend
  • token_frontend
  • token_backend
  • actions_frontend
  • actions_backend

如果其中任何一项服务达到或接近 100% CPU 利用率，或者内存接近其限制（默认情况下为 2 GB），则这些服务的资源配置可能需要增加。 请注意上述服务中哪些已经达到或接近极限。

3. 对达到限制的服务增加资源分配

  1. 使用 SSH 登录到管理 shell。 有关详细信息，请参阅“访问管理 shell (SSH)”。

  2. 运行以下命令，查看可用于分配的资源：

    nomad node status -self

    在输出中找到“Allocated Resources（分配的资源）”部分。 这类似于以下示例：

    Allocated Resources
CPU              Memory          Disk
7740/49600 MHZ   23 GiB/32 GiB   4.4 GiB/7.9 GiB

    对于 CPU 和内存，这显示了分配给所有服务的量（左侧值）以及可用量（右侧值） 。 在上面的示例中，总共有 32 GiB 内存，分配 23 GiB。 这意味着有 9 GiB 内存可供分配。

    Warning

    请注意不要分配超过可用资源总量，否则服务将无法启动。

  3. 将目录更改为 /etc/consul-templates/etc/nomad-jobs/actions：

    cd /etc/consul-templates/etc/nomad-jobs/actions

    在此目录中，有三个文件与上面的 GitHub Actions 服务对应：

    • mps.hcl.ctmpl
    • token.hcl.ctmpl
    • actions.hcl.ctmpl

  4. 对于确定需要调整的服务，请打开相应的文件，并找到如下所示的 resources 组：

    resources {
  cpu = 512
  memory = 2048
  network {
    port "http" { }
  }
}

    CPU 资源的值以 MHz 为单位，而内存资源以 MB 为单位。

    例如，要将上述示例中的资源限制增加到 1 GHz 的 CPU 和 4 GB 的内存，则将其更改为：

    resources {
  cpu = 1024
  memory = 4096
  network {
    port "http" { }
  }
}

  5. 保存并退出该文件。

  6. 运行 ghe-config-apply 来应用更改。

    运行 ghe-config-apply 时，如果输出类似于 Failed to run nomad job '/etc/nomad-jobs/<name>.hcl'，则说明在更改时可能过度了分配 CPU 或内存资源。 如果发生这种情况，请再次编辑配置文件，并降低分配的 CPU 或内存，然后重新运行 ghe-config-apply。

  7. 应用配置后，运行 ghe-actions-check 以验证 GitHub Actions 服务是否正常运行。

Dependabot 触发现有工作流程时的故障疑难解答

为 你的 GitHub Enterprise Server 实例 设置 Dependabot 更新后，当现有工作流由 Dependabot 事件触发时，你可能会看到失败。

默认情况下，由 Dependabot 从 push、pull_request、pull_request_review 或 pull_request_review_comment 事件中触发的 GitHub Actions 工作流运行被视为从存储库分支中打开。 与其他参与者触发的工作流不同，这意味着它们会接收一个只读 GITHUB_TOKEN，并且无权访问任何通常可用的机密。 这将导致尝试写入仓库的任何工作流程在由 Dependabot 触发时失败。

有三种方法可以解决此问题：

  1. 可以更新工作流，使其不再由 Dependabot 使用如下表达式触发：if: github.actor != 'dependabot[bot]'。 有关详细信息，请参阅“对工作流和操作中的表达式求值”。
  2. 可以修改工作流以使用包含 pull_request_target 的两步过程，该过程没有这些限制。 有关详细信息，请参阅“通过 GitHub Actions 自动化 Dependabot”。
  3. 可为由 Dependabot 触发的工作流提供对机密的访问权限，并允许 permissions 术语增加 GITHUB_TOKEN 的默认范围。 有关详细信息，请参阅下面的“提供由 Dependabot 访问机密触发的工作流以及增加的权限”。

提供由 Dependabot 机密访问权限和增加权限触发的工作流程

  1. 使用 SSH 登录到管理 shell。 有关详细信息，请参阅“访问管理 shell (SSH)”。

  2. 若要删除 Dependabot 在 你的 GitHub Enterprise Server 实例 上触发的工作流限制，请使用以下命令。

    ghe-config app.actions.disable-dependabot-enforcement true

  3. 应用配置。

    ghe-config-apply

  4. 返回到 GitHub Enterprise Server。

GitHub Actions 中的捆绑操作疑难解答

如果在 GitHub Enterprise Server 中安装 GitHub Actions 时收到以下错误，则可以通过安装官方捆绑操作和工作流模板来解决此问题。

A part of the Actions setup had problems and needs an administrator to resolve.

若要在 GitHub Enterprise Server 的指定组织内安装官方捆绑操作和工作流模板，请按照此过程进行操作。

  1. 确定将要存储官方捆绑操作和工作流模板的组织。 您可以创建新组织或重新使用现有组织。

  2. 使用 SSH 登录到管理 shell。 有关详细信息，请参阅“访问管理 shell (SSH)”。

  3. 要将组织指定为存储捆绑操作的位置，请使用 ghe-config 命令，将 ORGANIZATION 替换为组织的名称。

    ghe-config app.actions.actions-org ORGANIZATION

    and：

    ghe-config app.actions.github-org ORGANIZATION

  4. 要将捆绑操作添加到您的组织，请取消设置 SHA。

    ghe-config --unset 'app.actions.actions-repos-sha1sum'

  5. 应用配置。

    ghe-config-apply

完成这些步骤后，你可以在“GitHub Actions for GitHub Enterprise Server 使用入门”中继续配置 GitHub Actions。