Jenkins 说构建成功或失败,但它能否确定导致构建失败的确切提交(和作者!)?
这个问题似乎表明没有。
编辑:来自我与佩斯的交流:
我看到的是“包括罪魁祸首”,这是自上次构建以来的每个人。我不想要那个。我想要罪魁祸首,詹金斯在做二进制搜索。如果 Jenkins 进行两次构建 10 次提交,我不想要 10 个可能的罪魁祸首,我希望它找到一个.
我还没有听说如何做到这一点。
该页面在谈论“查找错误”插件,而不是正常的构建周期。根据设置的方式,Jenkins 可以识别导致失败的确切提交和作者。如果 Jenkins 安装了适当的源代码控制插件并配置为了解构建所绑定的存储库,那么对于每个构建,它将列出自上次构建以来的更改。
此外,Jenkins 在其许多报告插件中都有能力责怪有问题的提交者。例如,它可以向做出错误提交的开发人员发送有关构建失败的电子邮件通知。
然而,许多设置让 Jenkins 很难知道。例如,如果 Jenkins 被配置为每日构建,那么可能有很多提交可能会导致问题。Jenkins 也可能未配置为了解源代码控制存储库,或者没有源代码控制存储库。所有这些问题都可能导致 Jenkins 无法识别构建破坏者。
特别是对于发送错误提交者的电子邮件,您可以使用email-ext插件,该插件具有向自上次成功构建以来提交的每个人发送电子邮件的选项。
对于这个主题的幽默看法,请查看这个方法。
我认为您所要求的在某些情况下是不可能的。确定谁是罪魁祸首需要深入了解只有人类才能决定的冲突解决方案。即便如此,有时必须让经理参与才能进行仲裁。例如,假设您获得 3 个提交(A、B、C),它们取决于预先存在的定义。但是,另一个提交 (D) 会修改该函数的行为。你还原哪个?也许商业计划是保持 A、B、C 原样并将 D 恢复到原始状态。相反,修改 A、B、C 以适应 D 的变化也是可能的。
在机器可以处理仲裁的情况下,单元测试和静态分析器负责确定罪魁祸首(尽管仍然不完美)。静态分析器有时会内置向违规者发送电子邮件的功能。可以编写单元测试来通知负责失败测试的团队或团队成员。两者都可以以相同的方式工作,以确定谁是失败的特定行上的最后一个提交者。不过,如果链接有问题,那么也许某些成员应该与特定的 makefile 相关联。