企业 GitHub Actions 故障排除

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

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

使用 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 Enterprise Server 实例上配置了 HTTP 代理服务器 ,则必须添加 localhost127.0.0.1HTTP 代理排除 列表中。 有关更改代理设置的更多信息,请参阅“配置出站 Web 代理服务器”。

如果这些设置未正确配置,则在设置或更改 GitHub Actions 配置时可能会收到诸如 Resource unexpectedly moved to https://(资源意外移动到 https://)<IP_ADDRESS>的错误。

运行器在更改主机名后未连接到 GitHub Enterprise Server

如果更改 您的 GitHub Enterprise Server 实例 的主机名,自托管运行器将无法连接到旧主机名,并且不会执行任何作业。

您将需要更新自托管运行器的配置,以对 您的 GitHub Enterprise Server 实例 使用新的主机名。 每个自托管运行器将需要以下程序之一:

  • 在自托管的运行器应用程序目录中,编辑 .runner. redentials 文件以将旧主机名替换为新主机名,然后重新启动自托管的运行器应用程序。
  • 使用 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 内存可供分配。

    警告:小心不要分配超过可用资源总额,否则服务将无法启动。

  3. 将目录更改为 /etc/consult-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 服务是否正常运行。

此文档对您有帮助吗?隐私政策

帮助我们创建出色的文档!

所有 GitHub 文档都是开源的。看到错误或不清楚的内容了吗?提交拉取请求。

做出贡献

或, 了解如何参与。