如何配置Travis-CI以构建拉取请求并合并到无冗余主服务器

用“ BDD”表示：

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

当我创建请求请求时
，Travis应该构建最新的提交

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

当我将拉取请求合并到母版时
，Travis应该构建母版

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

• 同时启用这两个选项会使Travis将两次构建每个Pull Request
  • 一次在该分支上提交
  • 并再次将该分支合并提交到其目的地
• 仅启用“构建PR”会导致PR的构建，但不会导致合并后的构建（即在主数据库上）。
• 通过构建对回购协议的所有推送，启用“推送”蛮力将满足上述条件。您可以尝试通过列入白名单和黑名单的分支机构来欺骗事物，但是除非您严格遵守分支机构的名称，否则这可能会咬住您。

这在Travis-CI文档和GH问题＃3241中有更多解释。

任何人都知道满足上述条件的配置吗？

我最终发现了另一个GH问题（＃2111），这使我有了尝试同时启用PR和推送功能的想法，但白名单将推送内容限制为特定分支。这似乎满足了我的工作流程标准。这是我所做的：

1. 在回购的Travis设置中同时启用PR和分支推送：

2. 更改.travis.yml为白名单master分支（即仅建立对主服务器的推送）：

分支机构：
  只要： 
    -大师

3. 通过创建包含.travis.yml更改的PR以及具有一些空提交的另一个PR来测试它，以验证它也适用于派生。

4. 从master验证成功的合并提交构建。

刚刚在travis文档中找到

添加到.travis.yml

if: type = push

或者：

if: type = pull_request

假设您要构建所有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的网站上阅读有关条件和条件构建的更多信息。

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

我提出了一个问题，寻求更好的解决方案。

如果您不仅要测试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

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

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

有一个origin仓库，它是完成所有发行版的主要仓库。

我希望所有到源master分支的请求都应该只用Travis构建一次，而不管它来自派生的回购协议还是其本身的任何其他分支origin。

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

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