我很热衷于不要让项目质量失控。
我了解在某些情况下,警告可能是有道理的,但我担心警告的数量会随着时间的推移而增加。
我有一个Azure DevOps构建(门控提交)管道,我只允许10条警告,以便在某个时候开发人员必须解决他们的警告。
如果警告计数超过一定数量,是否可以计算警告并阻塞管道?
感谢!
答案 0 :(得分:1)
对于您而言,我建议将警告视为错误,这样,如果项目包含警告,则门控提交将失败-这是dotnet core的示例:
dotnet build /warnaserror
在某些情况下,开发人员仍然可以选择禁用警告:
#pragma warning disable CS8632
// Here I do something that nullable references without context but I know what I do because...
#pragma warning restore CS8632
答案 1 :(得分:1)
如果警告计数超过一定数量,是否可以计算警告并阻塞管道?
答案是肯定的。
有一个很好的扩展可以满足您的需求:Build Quality Checks。它提供了大量构建质量检查,您可以将这些构建质量检查添加到构建过程中。
有一个选项警告阈值,可用于指定最大警告数。如果超过此数量,构建将失败。
即使策略破坏了构建,您仍然可以获得测试结果以及编译输出。