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中，有一个选项可以确保在合并之前受保护的分支是最新的。＆＃34;在合并之前要求分支是最新的＆＃34;。如果我们选择这个选项，PR2和PR3不能在开发中合并，我们得到更新分支＆＃34; 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作业拆分为两个作业：一个＆＃34;验证＆＃ 34;工作和一个＆＃34;建立＆＃34;工作
更改您的管道：例如，您可以让CI自动验证新的PR，但需要一些手动步骤将PR合并到master中并手动触发结果上的构建作业

同时构建多个github pull请求，但合并最新分支

1 个答案: