构建拉取请求
拉取请求构建是 Travis CI 的重要组成部分。每当在 GitHub 上打开拉取请求时，Travis CI 都会构建它并更新拉取请求页面上的状态图标。
您可以通过查看 Web UI 中的 DRAFT 标签来确定拉取请求在被贡献者视为草稿时是否被构建。查看 GitHub 上 草稿拉取请求事件 的工作原理。
如何构建拉取请求 #
当在 GitHub 上打开拉取请求时，Travis CI 会收到通知并运行构建。在构建期间，我们会将拉取请求的状态图标更新为以下状态之一
- 构建仍在运行的警告。
- 构建失败的通知 - 不应合并拉取请求。
- 构建成功的通知 - 可以合并拉取请求。
Travis CI 在拉取请求首次打开时以及每当向拉取请求添加提交时构建拉取请求。我们不是构建已推送到拉取请求所属分支的提交，而是构建源分支与上游分支之间的合并。
要仅在推送事件而不是拉取请求上构建，请在您的仓库设置中禁用“在拉取请求上构建”。
要仅构建针对特定分支的拉取请求，可以使用 branches: only: 键，这也会限制触发构建的分支。
拉取请求和安全限制 #
拉取请求最重要的限制是关于安全环境变量和加密数据的。
从上游仓库的分支发送的拉取请求（我们称之为“外部拉取请求”）可能会被操纵以公开环境变量。上游仓库的维护者将无法防止此攻击，因为任何在 GitHub 上分叉仓库的人都可以发送拉取请求。
Travis CI 仅对来自同一仓库的拉取请求（“内部拉取请求”）提供加密变量和数据。这些被认为是可信的，因为只有具有对仓库的写入权限的成员才能发送它们。
即使在 Travis CI 中未设置某些仓库设置的情况下，从分叉仓库发送的拉取请求也无法访问加密变量或数据，即使这些变量或数据在分叉源项目中定义也是如此。
仓库设置 - 分叉 #
从 2022 年 3 月 1 日起，Git 分叉仓库的仓库安全设置可用。
对于 Git 仓库，您可以管理每个仓库在 Travis CI 中，当构建被触发为从分叉仓库提交拉取请求的结果时，如何处理 环境变量 和 自定义 SSH 密钥。两个设置专门用于此目的，允许您自定义安全与协作设置。
- 基本仓库 - 一个被其他人分叉的 Git 仓库
- 分叉 或 分叉仓库 - 从基本仓库分叉的任何 Git 仓库
- PR - 拉取请求（例如，在 GitHub、BitBucket、GitLab 中）或合并请求（在 Assembla 中）
请注意：在2022 年 3 月 1 日之前在 Travis CI 中激活的仓库将具有“与分叉（PR）共享加密环境变量”设置设置为关闭。如有必要，请验证您的协作模型（尤其是公共仓库）。“与分叉（PR）共享 SSH 密钥”将对私有仓库设置为打开，以免破坏太多协作设置。对于在2022 年 3 月 1 日之后在 Travis CI 中激活的任何仓库，仓库设置将默认设置为关闭。对于在2022 年 3 月 1 日之后在 Travis CI 中激活的仓库，您可能需要根据您的协作模型考虑更改默认设置。
与分叉（PR）共享加密环境变量 #
此设置决定了基本仓库的加密环境变量是否将在分叉到基本拉取请求（分叉仓库将更改合并到基本仓库）中与分叉仓库共享。
在基本到基本拉取请求的情况下（更改从基本仓库合并到自身），加密环境变量将始终可用。这允许合作者使用仓库加密环境变量提交拉取请求，并保留已配置的现有检查，例如，在 GitHub 中。
在分叉到分叉拉取请求的情况下（更改从分叉仓库合并到自身），基本仓库的加密环境变量将永远不可用。因此，需要直接在分叉仓库中替换或绕过它们。
在分叉到基本拉取请求的情况下
- 如果此设置打开，加密环境变量将对分叉仓库可用，这意味着分叉仓库中的构建将可以访问来自基本仓库的加密环境变量。这可能是一种不太安全的方法，但允许使用分叉和拉取请求（PR）进行协作。
- 如果此设置关闭，并且构建依赖于任何加密环境变量，则从分叉到基本仓库的 PR 将失败。这通过限制从分叉访问它们来保护您的基本仓库加密环境变量。
与分叉（PR）共享 SSH 密钥 #
请注意：“与分叉（PR）共享 SSH 密钥”仓库设置仅适用于 travis-ci.com 环境中的私有仓库。
此设置决定了来自基本仓库的自定义 SSH 密钥是否将在分叉到基本拉取请求（更改从分叉仓库合并到基本仓库）中与分叉仓库共享。在基本到基本拉取请求的情况下（更改从基本仓库合并到自身），自定义 SSH 密钥将始终可用。
在分叉到分叉拉取请求的情况下（更改从分叉仓库合并到自身），来自基本仓库的自定义 SSH 密钥将永远不可用。
在分叉到基本拉取请求的情况下
- 如果此设置打开，来自基本仓库的自定义 SSH 密钥将对分叉仓库可用，这意味着分叉仓库中的构建将能够使用来自基本仓库的自定义 SSH 密钥。如果您的协作模型需要使用来自分叉仓库的拉取请求（PR）或定义了依赖项（依赖于来自基本仓库的 SSH 密钥），请考虑将其设置为打开。
- 如果此设置关闭，并且构建依赖于自定义 SSH 密钥（例如，用于获取一些其他依赖项），它将失败并出现无访问权限错误。
如果您禁用了与分支共享秘密的设置，并且您的构建依赖于加密变量来运行（例如，使用 BrowserStack 或 Sauce Labs 运行 Selenium 测试），您的构建需要考虑到这一点。您将无法为来自外部贡献者的拉取请求运行这些测试。
为了解决这个问题，请将这些测试限制在环境变量可用的情况下，或完全禁用它们以进行拉取请求，如下例所示
script:
- 'if [ "$TRAVIS_PULL_REQUEST" != "false" ]; then bash ./travis/run_on_pull_requests; fi'
- 'if [ "$TRAVIS_PULL_REQUEST" = "false" ]; then bash ./travis/run_on_non_pull_requests; fi'
我的拉取请求没有被构建 #
如果拉取请求没有被构建或没有出现在 Travis CI 的用户界面中，通常意味着它无法被合并。我们依赖于 GitHub 在源分支中的更改和拉取请求发送到的上游分支之间透明创建的合并提交。
因此，当您创建或更新拉取请求时，如果 Travis CI 没有为其创建构建，请确保该拉取请求可合并。如果不是，请将其重新设置为上游分支并解决任何合并冲突。当您将修复推送到拉取请求时，Travis CI 将很乐意构建它们。
Travis CI 目前也不在更新上游分支时构建拉取请求，因为这会导致过多的新构建。
如果拉取请求已被合并，则您无法重新运行作业。您会收到类似的错误：
The command "eval git fetch origin +refs/pull/994/merge: " failed
恢复已合并拉取请求的分支不会触发构建，也不会将新的提交推送到已合并的分支。
拉取请求上的“双重构建” #
如果您在 GitHub 拉取请求中看到两个构建状态图标，这意味着有一个构建用于分支，另一个构建用于拉取请求本身（实际上是用于将头部分支与拉取请求中指定的基础分支合并的构建）。