使用gerrit长时间变性

Question

我们的项目是多模块maven项目。该项目依赖于另一个多模块maven项目。 poms的关系（聚合和继承明智）就像

parent-super-pom
|---parent-module-1
|---parent-module-2
|---parent-module-3
|---...
|---parent-module-n
|---child-super-pom
    |---child-module-1
    |---child-module-2
    |---child-module-3
    |---child-module-4

parent项目中的所有内容都由一个单独的团队管理，我们称之为framework。 child项目中的所有内容都由我们的团队管理，我们称之为product。

现在framework升级为使用spring-boot以及许多其他重大变化。我们需要开始开发以升级product以使用framework的最新技术。这个升级过程大约需要一个月（有许多不可编译的提交），因为需要注意很多更改才能使应用程序正常工作。与此同时，product也将在旧的maven环境中自行开发功能。接近这种情况的最佳方法是什么？

我们使用gerrit代码审查。这些变化首先在gerrit上推动，有自动jenkins作业触发器来运行基本测试。只有在构建通过时才能提交更改。还有一些构建可以根据某些触发器通过gerrit注释来执行，例如运行耗时的Web测试，集成测试等。

我的想法

在下面的上下文中强制推动我的意思是它必须绕过gerrit，即直接推到分支而不是实际的力推，重新创建git历史

• 在product中创建一个功能分支进行升级，比如feature/upgrade
• 确保为此分支w.r.t设置临时CI作业。新的环境，包括按需的环境
• 将升级所需的更改推送到此分支，直到应用程序可以正常运行
• 不时在master上重新启动分支，以避免在升级结束时出现批量冲突（需要强制推送feature/upgrade）
• 最后，将所有更改从feature/upgrade推送到master（需要强制推送master），现在在master上配置CI作业以开始使用类似于新创建的临时作业中的配置

这个想法的缺陷是强制推动。我们确保分支机构不会受到这样的推动，因为它会使分支机构容易出错，并且组织中只有少数人可以提交此类内容。可能是我不知道我可以利用的一些细菌特征，或者我的想法是完全错误的。我需要知道处理这种情况的最佳方法是什么。

Answer 1

为什么不设置监视gerrit事件的小进程，如果将提交推送到refs/for/$your_feature_branch，则会自动将Verified标志设置为+1。您甚至可以等待Jenkins将Verified设置为该分支上的任何值，然后再根据该事件设置Verified再次+1。通过这种方式，您可以保证能够独立于Jenkins中失败的构建单独合并您的提交。