我正在使用具有拉取请求构建和分支构建的 Travis CI。我确信这对其他 CI 服务来说很常见。
如果我有一个develop 分支和一个feature/A 分支，那么当我从feature/A 打开一个针对develop 的拉取请求时，拉取请求构建会运行我的单元测试。
假设我的单元测试通过，我合并拉取请求和分支构建触发器，因为新提交到 develop。此分支构建构建我的容器并将其部署到开发环境。
我是否应该在我的分支构建中运行与拉取请求构建期间相同的单元测试套件，还是可以安全地假设因为拉取请求测试通过了，分支构建也可以？运行这些测试会浪费周期吗？
【问题讨论】：
标签： git github continuous-integration travis-ci devops
这实际上是一个好问题，而且一点也不罕见，根据我的经验，再次运行 tests 是个好主意，除非你是唯一一个 making pull requests 到 branch，假设你的 @987654324 @ 运行正确，但有人在您之前创建了 pull request，并且您的 feature-branch 没有与该代码保持同步，develop-branch 中的某些代码 merged 可能会影响您已经使用的某些流程tested，这可能会导致您的代码出现fail/misbehavior。避免将这些misbehaviors 推送到实时环境的一种方法是在接受pull request 后立即再次运行tests，这将为您的管道增加一些周期，但我认为它可以缓解hotfixes/issues。
【讨论】：
事实上，它最终是一个权衡的问题......
有很多变数最终决定将限制放在哪里（以后可能会进一步推动）。
您应该了解，无法找到并修复 CI 工作流程的所有错误和问题，因此您必须找到获得预期质量的好方法。
这取决于：
master 分支的质量水平以及您对早期反馈的重视程度。如果您使用 GitHub，该服务会模拟您的 PR 与目标分支的合并，这就是您通常构建的内容。所以，从这个角度来看，合并后你不需要重建和测试你的目标分支。
但也有一些极端情况......
如果在你的 PR 中最后一次提交之后合并了另一个 PR，则不会重新构建 PR（GitHub 只需验证它是否仍然可合并）。
这里有两种解决方案：
rebase 或同步 merge），然后再合并它 => 无需重建目标分支。从质量的角度来看，最好构建目标分支，因为它正在执行干净的构建，并且有时您在 PR 构建中没有发现一些极端情况。 如果您需要避免这些极端情况，因为您必须拥有非常高质量的产品，例如，生命或大量金钱，或者任何原因取决于构建的输出，您应该重新构建它。
如您所见，这完全取决于您的 CI 工作流程、预期质量和实施成本。
旁注：大多数时候，构建目标分支以创建干净的工件仍然有用（因此您在 PR 中执行的构建与目标分支不同）。所以这仍然是一个很好的做法......
【讨论】：