如何配置 Travis-CI 以构建拉取请求并合并到没有冗余的主控答案

【问题标题】：How to configure Travis-CI to build pull requests & merges to master w/o redundancy如何配置 Travis-CI 以构建拉取请求并合并到没有冗余的主控
【发布时间】：2020-05-24 16:54:25
【问题描述】：

用“BDD”术语来说：

背景：
鉴于我正在为 GH 回购做出贡献

当我创建拉取请求时
然后 Travis 应该构建最新的提交

当我推送到现有的拉取请求时
然后 Travis 应该构建最新的提交

当我将拉取请求合并到 master
那么 Travis 应该构建 master

我对 Travis-CI 的“构建推送”和“构建 PRs”设置感到困惑，因为：

同时启用这两种方法会导致每个拉取请求由 Travis 构建两次
- 在该分支上提交一次
- 再次将该分支合并提交到其目标
仅启用“构建 PR”会导致构建 PR，但不会导致合并后构建（即在主服务器上）。
启用“推送”蛮力通过构建所有推送到存储库来满足上述标准。您可以尝试通过将分支列入白名单和黑名单来解决问题，但除非您对分支名称严格遵守纪律，否则这可能会咬到您。

这在Travis-CI docs 和GH issue #3241 中有更多解释。

有人知道满足上述条件的配置吗？

【问题讨论】：

分支构建和 PR 构建是不同的构建，可以有不同的结果。分支构建只是分支的尖端。 PR 构建是合并到 master 的分支的尖端。如果您在那时将分支合并到主控，这实际上会发生。如果分支打开后其他东西已经被合并到master，所以无法进行快进合并，这将与分支构建不同。

标签： github travis-ci pull-request

【解决方案1】：

我最终发现了另一个 GH 问题 (#2111)，这给了我尝试同时启用 PR 和推送的想法，但使用白名单来限制推送到特定分支。这似乎满足了我的工作流程的标准。这是我所做的：

在仓库的 Travis 设置中启用 PR 和分支推送：

将 .travis.yml 更改为 white-list master branch（即仅构建推送到主服务器）：

分支机构：只要： - 掌握

通过创建 PR with the .travis.yml change 和另一个带有一些空提交的 PR 来对其进行测试 works for forks too。
验证successful merge commit build from master。

【讨论】：

确认这项工作。看到这个pull request。
这对于指向 master 以外的其他内容的子功能分支 PR 是否仍然有效？我相信这依赖于 Travis 的 PR 构建环境变量的一个奇怪的怪癖，并且不适用于这种情况。
我认为应该这样做，因为它被配置为构建所有拉取请求（无论基础分支如何），但仅限于构建 pushs 到 master。
@fotinakis - GitHub 中有三个选项对应于三种不同类型的合并。选择保留所有子分支/功能的选项以将它们包含在推送中。然后你可能需要处理 travis.yml，我猜，以获得特定的分支/功能或排除
这不适用于不针对 master 的拉取请求 - 它们根本不会构建。

【解决方案2】：

刚刚在travis docs找到

添加到 .travis.yml

if: type = push

或者：

if: type = pull_request

【讨论】：

这个，但下面的@Corey Noel 有一个更完整的答案，我用于我们的答案

【解决方案3】：

假设您要构建所有 PR，类似以下的内容就可以解决问题。在设置页面上同时启用分支和 PR 构建，并将此行作为 travis.yml 中的第一行：

if: (type = push AND branch IN (master, dev)) OR (type = pull_request AND NOT branch =~ /no-ci/)

这将尝试在所有推送上进行推送构建，并在所有推送上构建 PR 到打开的 PR，但会过滤掉任何不符合条件的内容。您可能需要稍微修改一下 - 关于不构建名称中包含 no-ci 的分支的条款显然是可选的，并且您可能没有两个始终希望在其上运行构建的分支。

您可以在 Travis 网站上的 conditions 和 conditional builds 上阅读更多内容。

【讨论】：

谢谢，这正是我们所需要的！

【解决方案4】：

接受的答案中描述的白名单方法有一些重大限制。特别是，它不支持在不打开 PR 的情况下非冗余构建任意分支。

我打开了an issue asking for a better solution。

【讨论】：

【解决方案5】：

如果您不仅想测试 master 分支，还想测试其他一些分支，您可以使用下一个工作流程：

保持“构建推送”和“构建拉取请求”均开启
将branches:except 指令添加到您的.travis.yml：
```
branches:
  except:
    - /^pr\..*/
```

在此配置中：

对分支feature-A 的任何提交都会触发构建
对分支pr.feature-A 的任何提交都不会触发构建
如果在打开的拉取请求中使用分支pr.feature-A，则将触发构建

工作流程示例

多个开发者共享的临时 WIP 分支：wip.feature-A，任何对该分支的提交都会触发构建
当分支准备好合并到 master 时，您可以将其从 wip.feature-A 重命名为 pr.feature-A 并打开拉取请求
如果在审查拉取请求时你想应用新的修复，只需推送到pr.feature-A

在上述所有步骤中，只会触发一个构建。

【讨论】：

【解决方案6】：

对于我正在使用的其中一个存储库，这是我想要的：

有一个 origin 存储库，它是执行所有发布的主要存储库。

我希望所有来自 master 分支的拉取请求都应该只用 Travis一次构建，而不管它来自 forked 存储库的事实或origin 本身的任何其他分支。

对于这种情况，这就像一个魅力

if: (type == push) OR (type == pull_request AND fork == true)

【讨论】：