【发布时间】:2011-09-05 07:01:03
【问题描述】:
当某些指标的趋势不好时,Sonar 是否提供任何方法来发出警报并导致构建失败?
背景:在我们的遗留项目中,例如对代码覆盖率使用静态阈值(“覆盖率低于 80% 时发出红色警报”)没有多大意义。但我们希望确保覆盖率不会进一步下降。
请不要就使用限制较少的规则集来降低标准提供任何建议。在我们的案例中,这是没有选择的。
【问题讨论】:
当某些指标的趋势不好时,Sonar 是否提供任何方法来发出警报并导致构建失败?
背景:在我们的遗留项目中,例如对代码覆盖率使用静态阈值(“覆盖率低于 80% 时发出红色警报”)没有多大意义。但我们希望确保覆盖率不会进一步下降。
请不要就使用限制较少的规则集来降低标准提供任何建议。在我们的案例中,这是没有选择的。
【问题讨论】:
如果您违反质量配置文件中的警告或错误阈值设置,有一个构建中断插件将导致构建失败。
插件详情在这里:
http://docs.sonarqube.org/display/PLUG/Build+Breaker+Plugin
不知道有任何功能可以让您了解指标趋势。
我们使用 Sonar 作为发布过程的最后第二步。构建破坏者确保发布不会违反预定的质量标准。
【讨论】:
我们尝试了完全相同的方法,使用了构建中断插件。一段时间后,发现它太不灵活(而且配置 Sonar 是一团糟),所以我们从 sonar 转移到 Jenkins/Hudson 插件,如 Cobertura(用于代码覆盖)或 PMD 用于代码样式:
使用这些插件,可以进行非常精细的设置,例如将构建设置为在
【讨论】:
与此同时,我们编写了自己的 buildbreaker 脚本,在我们的构建中执行。我们使用 Groovy 查询 Sonar 的 REST API 以检索一组特定的指标(包括它们的历史值)。指标的检索由为我们整个部门提供的构建插件提供。
每个团队都可以使用一组关于必须为其项目验证的指标的规则来参数化他们的构建。当然,规则也提供为 Groovy sn-ps :-)
典型的有:
然后可以将不良发现用于破坏构建或仅用于报告。
【讨论】: