同时构建多个 github 拉取请求，但合并最新分支上的每个 PR

Question

假设我们正在使用 Jenkins、Teamcity 或其他工具在 github 中构建（CI）每个拉取请求，并在构建成功时合并 PR。每个 PR 都必须建立在最新的分支上。想知道人们是如何做到这一点的吗？

PRs    Start Time   Jenkins Build      Build Finished

PR1   (10:00) ---> Building(30 mins) -->10:30  ---->  Merged in Develop
PR2   (10:05) ---> Building(30 mins) -->10:35  ---->  Merged in Develop
PR3   (10:10) ---> Building(30 mins) -->10:40  ---->  Merged in Develop

我对这种方法有疑问。 PR1 合并到开发分支后（10:30），PR2 和 PR3 不再在最新分支上构建，它们处于开发分支的旧状态（PR1 合并之前）。

在 Github 中，有一个选项可以确保受保护的分支在合并之前是最新的。 “要求分支在合并之前是最新的”。如果我们选择这个选项，PR2 和 PR3 不能在开发中合并，我们会为 PR 启用“更新分支”按钮，这将确保 PR 是从开发分支重新建立的。

现在 PR2 和 P3 是基于开发分支重新构建的，但没有在最新代码上进行验证，所以我们再次构建它们。这需要更多时间来构建每个 PR。它就像构建的 2 到 3 次。

你们是如何在你们的组织中实现这一目标的？

Answer 1

事实：

• 如果您的验证过程需要 30 分钟，
• 如果您需要验证：
  1. PR1一个人
  2. PR2 在经过验证的 PR1 之上
  3. PR3 在经过验证的 PR1 + PR2 之上

然后：

• 您至少需要 1 小时 30 分才能整合 3 个 PR

如何改变这个：

• 优化您的构建作业
• 如果您可以通过仅运行一部分任务来验证 PR（例如：运行单元测试，但不需要构建静态资产...），请将您的 CI 作业分成两个作业：一个“验证”作业和一个“构建”工作
• 更改您的管道：例如，您可以让 CI 自动验证新 PR，但需要一些手动步骤将 PR 合并到 master 并在结果上手动触发构建作业