Travis CI Enterprise 故障排除指南

Travis CI Enterprise (TCIE) 3.x
Travis CI Enterprise (TCIE) 2.x
构建未启动
企业容器由于“上下文截止时间已过”错误而无法启动
Ubuntu 16.04 上的 travis-worker 未启动
构建因 Curl 证书错误而失败
用户帐户卡在同步状态
日志包含许多 GitHub API 422 错误
RabbiMQ AMQPS 问题导致构建作业永远不会入队

本文档提供了有关对 Travis CI Enterprise 安装进行故障排除的指南和建议。每个主题都包含一个常见问题及其解决策略。如果您对特定场景有疑问或遇到未涵盖的问题，请联系 enterprise@travis-ci.com 获取帮助。

Travis CI Enterprise (TCIE) 3.x #

TCIE 3.x 部署为 Kubernetes 集群。因此，以前使用单个 Docker 安装工作的travis bash 和travis console 将不再起作用。它们被特定的kubectl 命令行命令取代。

术语Worker 机器仍然表示处理和运行构建的 worker 实例。

Travis CI Enterprise (TCIE) 2.x #

在本指南中，我们将使用以下术语来指代 Travis CI Enterprise 2.x 安装的两个组件

平台机器：运行主要 Travis 组件（包括 Web 前端）的实例。
Worker 机器：处理和运行构建的 worker 实例。

请注意，本指南针对非高可用性 (HA) 设置。如果您需要 HA 设置的支持，请联系 enterprise@travis-ci.com。

构建未启动 #

问题 #

在 Travis CI Web UI 中，您会看到没有任何构建启动。构建要么没有可见状态，要么状态为queued。取消和重新启动构建无效。

策略 #

有一些不同的潜在方法可能有助于使构建再次运行。请按顺序尝试每个方法。

与 RabbitMQ 的连接已断开 #

企业平台使用 RabbitMQ 与 worker 机器通信以处理构建。在某些情况下，worker 机器可能与 RabbitMQ 断开连接，因此无法成功处理构建。这是一个已知问题，我们正在努力提供永久解决方案。

同时，要将所有内容恢复到正常工作状态，您可以手动重新启动 worker 机器。这可以通过通过ssh 连接到 worker 并运行以下命令来完成

$ sudo shutdown -r 0

这将立即重新启动机器。处理 worker 构建的程序（travis-worker）配置为在系统启动时自动启动，并应重新建立与 RabbitMQ 的连接。

配置问题 #

请检查 worker 机器是否已具备所有相关配置。为此，请使用 SSH 登录到 worker 机器并打开/etc/default/travis-enterprise。这是travis-worker 用于连接到平台机器的主要配置文件。

这是一个示例

# Default ENV variables for Travis Enterprise
# Uncomment and set, then restart `travis-worker` for
# them to take effect.

export TRAVIS_ENTERPRISE_BUILD_ENDPOINT="__build__"
export TRAVIS_ENTERPRISE_HOST="<your-travis-ci-enterprise-domain>"
export TRAVIS_ENTERPRISE_SECURITY_TOKEN="abc12345"
# export TRAVIS_WORKER_DOCKER_PRIVILEGED="true"

相关变量是TRAVIS_ENTERPRISE_HOST 和TRAVIS_ENTERPRISE_SECURITY_TOKEN。前者需要包含您用于访问 Travis CI Enterprise Web UI 的主域名。 travis-worker 进程使用此域名来访问平台机器。后者的值需要与在https://<your-travis-ci-enterprise-domain>:8800/settings 中找到的RabbitMQ 密码匹配。

如果您对此文件进行了更改，请运行以下命令使其生效

$ sudo restart travis-worker

安全组/防火墙中未打开端口 #

问题的一个来源可能是 worker 机器无法与平台机器通信。

这里我们区分了 AWS EC2 安装和在其他硬件上运行的安装。对于前者，需要根据机器配置安全组。为此，请按照我们的安装说明此处进行操作。如果您未使用 AWS EC2，请确保文档中列出的端口在您的防火墙中已打开。

SSL 验证问题 #

当 Github 尝试使用 Travis CI Enterprise 触发新构建时，可能会出现 SSL 验证错误。

要验证 Github 是否已成功传递 webhook 有效负载

转到您期望触发构建的 Github 中的存储库。
单击顶部菜单中的“设置”。
要查看为此存储库设置的 webhook，请单击“钩子”。
找到为您的 Travis CI Enterprise 域名创建的 webhook 并单击“编辑”。
滚动到页面底部的“最近交付”部分。

所有最近对 Travis CI Enterprise 的有效负载尝试都应存在。如果任何尝试失败并显示“无法使用给定的 CA 证书对对等证书进行身份验证”之类的消息，则根本原因很可能是您安装上的 SSL 证书设置。

根据您的配置，可能有多种方法可以解决此问题。我们关于SSL 证书管理的页面包含了 Travis CI Enterprise 中各种设置的说明。

Docker 版本不匹配 #

此问题有时会在 2017 年 11 月之前安装的 worker 或运行早于17.06.2-ce 的docker version 的系统上的维护后发生。发生这种情况时，/var/log/upstart/travis-worker.log 文件将包含以下行：Error response from daemon:client and server don't have same version。对于此问题，我们建议从头开始重新安装每个 worker在新的实例上。

请注意，将提取默认构建环境映像，您可能还需要重新应用自定义。

您正在运行 Enterprise v2.2 或更高版本 #

默认情况下，Enterprise Platform v2.2 或更高版本将尝试将构建路由到builds.trusty 队列。如果未运行 Trusty worker 来处理这些构建，或者如果目标是不同的发行版（例如xenial），则这可能会导致构建问题。

要解决此问题，请执行以下任一操作：

确保您已在新虚拟机实例上安装了 Trusty worker：Trusty 安装指南
覆盖默认排队行为以指定新队列。要覆盖默认队列，您必须访问位于https://<your-travis-ci-enterprise-domain>:8800/settings#override_default_dist_enable 的管理仪表板，并切换“覆盖默认构建环境”按钮。这将允许您根据您的需求和可用的 worker 指定新的默认值。

您正在运行 Enterprise v3.x 或更高版本 #

验证 Enterprise Platform 3.x 中配置的默认队列是否将构建路由到匹配的现有 worker。您可以选择通过在http://loclahost:8800 上运行管理控制台 UI，导航到“配置”并通过选择可用选项之一来更改“设置默认构建环境”选项来更改默认队列设置。

企业容器由于“上下文截止时间已过”错误而无法启动 #

此问题仅适用于 TCIE 2.x。TCIE 3.x 部署为 Kubernetes/microk8s 集群。

问题 #

在全新安装或配置更改后，企业容器无法启动，并且在位于https://<your-travis-ci-enterprise-domain>:8800/dashboard 的管理仪表板中可见以下错误

Ready state command canceled: context deadline exceeded

策略 #

GitHub OAuth 应用程序配置 #

上述错误可能是由于GitHub OAuth 应用程序中的配置不匹配造成的。请检查网站和回调 URL 均包含 Travis CI Enterprise 的主机名。如果您在此处发现不匹配，请从管理仪表板中重新启动 Travis 容器。

Ubuntu 16.04 上的 travis-worker 未启动 #

问题 #

travis-worker 已在 Ubuntu 16.04 (Xenial) 的全新安装上安装，没有问题。但是，命令sudo systemctl status travis-worker 显示它未运行。

此外，命令sudo journalctl -u travis-worker 包含以下错误

/usr/local/bin/travis-worker-wrapper: line 20: /var/tmp/travis-run.d/travis-worker: No such file or directory

策略 #

travis-worker 未运行的一个可能原因是systemctl 无法为环境文件创建临时目录。要解决此问题，请创建目录/var/tmp/travis-run.d/travis-worker 并通过以下方式分配写入权限：

$ mkdir -p /var/tmp/travis-run.d/
$ chown -R travis:travis /var/tmp/travis-run.d/

构建因 Curl 证书错误而失败 #

问题 #

构建失败并显示类似于以下内容的较长的curl 错误消息：

curl: (60) SSL certificate problem: unable to get local issuer certificate

这可能有多种原因，包括自动 nvm 更新或缓存错误。

策略 #

此错误很可能是由自签名证书引起的。在构建过程中，worker 容器会尝试从平台机器获取不同的文件。如果服务器最初使用自签名证书进行配置，则 curl 不信任此证书，因此会失败。虽然我们正在努力以永久的方式解决此问题，但目前唯一的解决方案是安装由受信任的证书颁发机构 (CA) 颁发的证书。这可以是免费的 Let’s Encrypt 证书或您选择的任何其他受信任的 CA。我们在 SSL 证书管理页面中有一个部分，以 Let’s Encrypt 为例，指导您完成安装过程。

用户帐户卡在同步状态 #

问题 #

一个或多个用户帐户卡在 is_syncing = true 状态。当您查询数据库时，当前正在同步的用户数量不会随着时间的推移而减少。示例

travis_production=> select count(*) from users where is_syncing=true;
 count
-------
  1027
(1 row)

策略 #

您可以通过运行以下命令重置卡住的用户帐户的 is_syncing 标志：

TCIE 3.x：在您的本地机器上运行 $ kubectl exec -it [travis-api-pod]j /app/script/console

TCIE 2.x：通过 SSH 登录到平台机器。运行 $ travis console

接下来，无论 TCIE 版本如何，都运行

>> User.where(is_syncing: true).count
>> ActiveRecord::Base.connection.execute('set statement_timeout to 60000')
>> User.update_all(is_syncing: false)

可能会发生组织也卡在同步状态的情况。由于组织本身没有 is_syncing 标志，因此所有属于它的用户都必须成功同步。

日志包含许多 GitHub API 422 错误 #

问题 #

在每次提交时，当构建运行时，会为给定的 SHA 创建一个提交状态。由于 GitHub 对每个存储库中 SHA 和上下文的 1,000 个状态的限制，如果创建了超过 1,000 个状态，则会导致验证错误。此问题在 GitHub Apps 集成中不应再出现，但会在 Webhooks 集成中出现。

策略 #

此问题的解决方法是手动重新同步用户帐户与 GitHub。这将为尚未达到任何 GitHub API 限制的用户帐户生成一个新的令牌。

下面列出了两个启动 Travis CI Enterprise 实例和 GitHub 实例之间同步的选项。

从 Travis CI Web 界面同步帐户 #

请受影响帐户的所有者（通常在日志中打印）将其与您的 GitHub 实例同步。为此，他们应该

打开 https://<your-travis-ci-enterprise-domain>。
在页面右上角，将鼠标悬停在用户图标上，然后从下拉菜单中选择“个人资料”。
在个人资料页面右上角，点击“同步帐户”。

使用管理员权限从 CLI 同步帐户 #

管理员也可以代表其他人启动同步

TCIE 3.X：通过手动强制 github-sync 重新运行同步

kubectl exec -it [travis-github-sync-pod] bundle exec bin/schedule users [login if single user]

TCIE 2.x：通过平台机器上的 travis CLI 工具

如果未提供 —logins=<GITHUB-LOGIN>，则此命令将触发每个用户的同步。如果您的 Travis CI Enterprise 实例上的用户总数很多，这可能会导致运行时间过长，并可能影响生产操作。

打开到平台机器的 SSH 连接。
通过运行 travis sync_users —logins=<GITHUB-LOGIN> 启动同步。

RabbiMQ AMQPS 问题导致构建作业永远无法入队 #

此问题仅在 TCIE 3.x 中出现。TCIE 2.x Rabbit 不包含任何 AMQPS 支持。

问题 #

使用自签名证书时，Rabbit MQ AMQPS 将无法工作，这会导致作业永远排队。当使用 AMQPS 连接到 Rabbit 时，Worker 日志将指示安全问题。

策略 #

通过显式标记允许自签名证书来放宽安全限制。

SSH 到 worker 机器。将 export AMQP_INSECURE=true 添加到 /etc/default/travis-worker。重新启动 worker 实例。