用“BDD”术语来说：
背景：
鉴于我正在为 GH 存储库做出贡献
当我创建拉取请求时
然后 Travis 应该构建最新的提交
当我推送现有的拉取请求时
然后 Travis 应该构建最新的提交
当我将拉取请求合并到 master 时
那么 Travis 应该构建 master
我对 Travis-CI 的“构建推送”和“构建 PR”设置感到困惑，如下所示：
- Enabling both causes each Pull Request to be build twice by Travis
- 一次用于该分支上的提交
- 并再次将该分支合并提交到其目的地
- 仅启用“构建 PR”会导致构建 PR，但不会导致合并后构建（即在 master 上）。
- 启用“推”暴力通过构建满足上述标准all推送到仓库。您可以尝试通过将分支列入白名单和黑名单来欺骗事情，但这可能会咬伤您，除非您对分支名称有严格的纪律。
这在中进行了更多解释Travis-CI 文档 http://docs.travis-ci.com/user/pull-requests/ and GH 问题 #3241 https://github.com/travis-ci/travis-ci/issues/3241.
有谁知道满足上述标准的配置吗？
我最终发现了另一个 GH 问题（#2111 https://github.com/travis-ci/travis-ci/issues/2111）这给了我尝试启用 PR 和推送的想法，但使用白名单来限制推送到特定分支。这似乎满足我的工作流程的标准。这就是我所做的：
- 在存储库的 Travis 设置中启用 PR 和分支推送：
- Change
.travis.yml to 白名单master branch https://github.com/wikimedia/wikipedia-ios/pull/40/files#diff-354f30a63fb0907d4ad57269548329e3R9（即仅构建推送到 master）：
branches:
only:
- master
通过创建一个来测试它公关与.travis.yml change https://github.com/wikimedia/wikipedia-ios/pull/40，以及另一个带有一些空提交的 PR 来验证它也适用于叉子 https://github.com/wikimedia/wikipedia-ios/pull/41.
Verify 从 master 成功合并提交构建 https://travis-ci.org/wikimedia/wikipedia-ios/builds/74550311.
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
