如果我测试 Pull Request 构建，合并后是否需要运行相同的测试？

Question

我正在使用具有拉取请求构建和分支构建的 Travis CI。我确信这对于其他 CI 服务是常见的。

如果我有一个develop分支和一个feature/A分支，那么当我从feature/Atarget打开拉取请求时develop，拉取请求构建会运行我的单元测试。

假设我的单元测试通过，我合并拉取请求和分支构建触发器，因为对develop. 此分支构建构建我的容器并将其部署到开发环境。

我应该在我的分支构建上运行与拉取请求构建期间相同的单元测试套件，还是假设因为拉取请求测试通过，分支构建也会安全？运行这些测试会浪费周期吗？

Answer 1

这实际上是一个很好的问题，而且并不少见，根据我的经验，tests再次运行是一个好主意，除非您是唯一一个making pull requests这样做的人branch，假设您的tests运行正确但有人pull request在您之前做出了正确的选择，而您的feature-branch则不是了解最新的代码，可能是一些代码merged到develop-branch影响一些已经流到你tested，那可能会导致fail/misbehavior您的代码。避免将这些推misbehaviors送到实时环境的一种方法是tests在接受 a 后立即再次运行pull request，这将为您的管道增加一些周期，但我认为它可以减轻hotfixes/issues.

Answer 2

事实上，这最终会导致一个权衡问题......

有很多变数，最终由你来决定在哪里设置限制（稍后可能会进一步推动它）。

您应该明白，您将无法找到并修复 CI 工作流程中的所有错误和问题，因此您必须找到获得预期质量的好方法。

这取决于：

• 您期望您的master分支机构达到什么水平的质量，以及您对早期反馈的重视程度。
• 为了实现这一目标你将付出什么代价。

如果您使用 GitHub，该服务会模拟您的 PR 与目标分支的合并，这就是您通常构建的内容。因此，从这个角度来看，您不需要在合并后重建和测试目标分支。

但也有一些极端情况......

如果在 PR 中推送最后一次提交后合并另一个 PR，则不会重新构建 PR（GitHub 只需验证它是否仍然可合并）。

这里有两个解决方案：

1. 您设置为在合并之前强制同步（通过 arebase或sync merge）PR => 无需重建目标分支。
2. 没有强制 => 您需要构建目标分支。这将是您的“集成构建”。

从质量的角度来看，最好构建目标分支，因为它正在执行干净的构建，并且有时存在您在 PR 构建中未捕获的极端情况。如果您需要避免这些极端情况，因为您必须拥有非常高质量的产品，例如生命或高额金钱，或者任何取决于构建输出的原因，您应该再次构建它。

正如您所看到的，这一切都取决于您的 CI 工作流程、预期质量以及实施成本。

旁注：大多数时候，构建目标分支来创建干净的工件仍然很有用（因此您在 PR 中执行的构建与目标分支的构建不同）。所以这仍然是一个很好的做法......