Git 自动指责Jenkins的构建失败

我们的构建过程涉及Git、Gerrit和Jenkins。如果Jenkins构建被破坏，必须有人分析最新的提交，并将修复任务分配给各个提交者。自上一次稳定构建以来，所有提交的开发人员也会收到一封电子邮件，但这只是表示“构建已中断”

通过一些机器学习，似乎可以发现提交者“最有可能”导致测试失败。假设自上次稳定构建以来我有两次提交

Commit abcdef by Bob
Working on database reset logic
awesome-project/src/main/java/com/foobar/database/Reset.java
awesome-project/src/test/java/com/foobar/database/ResetTest.java

Commit abcdef by Fred
Add new VAT codes for Delaware
awesome-project/src/main/java/com/foobar/finance/VatTable.java
awesome-project/src/main/java/com/foobar/finance/VatLogicForDelawreImpl.java
awesome-project/src/test/java/com/foobar/statescenarios/DelawareTest.java

现在出现了构建失败

Stacktrace
java.lang.AssertionError: Expected <6> but was <7>
at com.foobar.finance.VatTableTest()

Stacktrace
java.lang.AssertionError:应为，但为
在com.foobar.finance.VatTableTest（）上

是否有插件会责怪Fred在为特拉华州添加新VAT行后没有更新VatTableTest？从stacktrace类、错误消息以及提交消息和提交的文件来看，这似乎是可能的（我很乐意接受“以下失败无法分配给特定提交”）

---

谢谢，Simon现在，我们将使用Email ext插件及其发送选项：

• 罪魁祸首（即自上次成功构建以来变更日志上的所有提交者）
• 导致生成开始失败的可疑对象（即第一个损坏的生成的更改日志上的提交者）

---

预防胜于治疗。合并请求生成使用gitlab/github解决了这个问题。您可以在合并之前构建、运行测试。我不知道它在Gerrit是怎么工作的。您是否使用gerrit进行代码审查，并且可以单独构建更改集。机器学习可以预测哪个提交破坏了构建？来吧难道你不能编写一个

git-bisect

会话来定位第一个不会生成的提交，并假设提交的作者是研究的起点吗？@Vishwanath，我们已经准备好gerrit构建验证。合并后仍然有很多构建步骤可能失败，也确实失败。用户界面测试是一个热点。@MarkAdelsberger，我相信我可以把一些东西拼凑在一起，但如果有一个插件的话，它可能不如一个已建立的插件好。“机器学习”可能是对该术语的误用，一些直接的regexp逻辑可能就足够了。是的，用于查找破坏某些内容（如构建）的特定提交的既定功能是

bisect

。。。既然如此，为什么会有人编写插件呢？