在Jenkins上构建/测试失败时的回滚提交

Question

好的，所以我看到很多这类问题没有真正的答案，而是反对它的警告。所以我明白为什么这样做会很烦人/危险，并且考虑过这些事情。但是，随着我的团队项目/管理层的建立（至少现在是如此），对于我们来说，当某人提交并且Jenkins检测到，拉取以及构建/修改时，能够撤消对BitBucket的提交是非常合理的。测试失败。有没有插件/方式来做到这一点？

Answer 1

它足够容易去除但是HEAD从分支提交，你真的不能安全的几个原因这样做在詹金斯的工作。

第一个原因是，你可能不处理单个提交。根据jenkins的配置情况（例如等待perioud），一个jenkins工作可能会包含多个提交。另外，用户可能一次推送多个提交。

其次，没有保证的承诺是开始詹金斯仍然会在HEAD当詹金斯已完成执行。所需要的只是在Jenkins执行期间有人推动，现在你将不得不尝试一个更复杂的rebase，如果没有人为干预，这可能是不可能的（特别是因为默认情况下，你不能自动重定义合并提交）。

我强烈的建议是，而不是试图从你的主人删除提交/开发分支考虑，而不是拥抱如下模式：像gitlabs负责合并到主。然后，您可以在jenkins中设置一个多分支管道作业，自动生成分支并配置gitlabs以防止合并，只要jenkins作业失败。这个想法是你为每个任务创建一个分支，然后jenkins将master合并到你的分支，并在你提交一个pull请求时建立它。只有这个构建成功后，才允许你合并到master中。

https://about.gitlab.com/2014/09/29/gitlab-flow/

Answer 2

如其他答案描述，更容易前检查后比。

其实还有另一个想法。它基本上重复了手动合并。如果有人能够成功实施它，并分享他们的经验，那将会很好。

1. 开发人员从未直接推送到master。 （*）
2. 新的内容推到master-rc，这始终是从master一个快进。他们可以直接从合并开发者的推拉请求中，在评论和一些预先检查之后推送。 （**）
3. 你的CI读取特定从当前master-rc提交A并测试它是否建立，测试通过等
4. 如果所有的检查都成功，则构建构件被存储，master快进到A。然后回到步骤3
5. 如果检查失败，master-rc重置为master，和什么用作者们大概有故障通知。然后返回到步骤3.（***）

这样，您始终确信master可以构建 - 因为它已经构建完毕。 （*）除特殊情况外，应取消生成中，master-rc重设为新的master，如出现错误。或者，如果你需要这个，那么你的master就坏了，你应该停止步骤2-6直到解决。 （**）有一个选择 - 要么他们独立于构建周期来完成，并且总是可能有一些新的内容超过master-rc - 请参阅下一个项目。或者他们等到周期开始。后者更方便，当有拉取请求时可以自动合并，因为有需要并且批准合并。 （***）如果master-rc中有更多内容比失败，它可以与失败一起丢弃，以便作者可以重新绑定它。或自动重新发布，但这已经是一些复杂化了。