Рассматривайте предупреждения как ошибки с помощью анализа SonarQube

Я пытался сделать так, чтобы мое решение не строилось на Visual Studio Team Services, когда появляются предупреждения. Я включил параметр в проекте в VS2017, чтобы обрабатывать предупреждения как ошибки, чтобы он не собирался.

Рассматривать предупреждения как ошибки, для которых установлено значение

Кроме того, для той же цели существует аргумент MsBuild, для которого в VSTS установлено значение true.

Рассматривать предупреждения как ошибки, для которых установлено значение true

Это работает, так как когда есть предупреждение, оно рассматривается как ошибка (например, неиспользуемый int является предупреждением и становится ошибкой, приводящей к сбою сборки).

Ошибка сборки

Однако при наличии анализа SonarQube сборка не завершается ошибкой. SonarQube по какой-то причине переопределяет TreatWarningsAsErrors = true, и предупреждение остается предупреждением.

Я не нашел возможности включить TreatWarningsAsError на сервере SonarQube. Я проверил правила, ворота качества и т. д.

сборка с помощью SonarQube

Как это должно быть сделано?

Меню опций с сервера SonarQube


person Consuela    schedule 01.11.2017    source источник
comment
Обходной путь заключается в том, что вы можете клонировать задачу сборки Visual Studio из задач SonarQube,   -  person starian chen-MSFT    schedule 02.11.2017


Ответы (2)


С практической точки зрения нет особого смысла использовать сканер SonarQube с TreatWarningsAsErrors=true, потому что, когда сборка сломается, наши анализаторы не получат результатов сборки, заключительный шаг не будет выполнен, и никакие проблемы не будут отправлены в SonarQube. Если в ваших сборках нет проблем, нет причин использовать SonarQube. К тому же с TreatWarningsAsErrors=true вы будете вынуждены все исправлять заранее, либо долго жить с неудачными билдами, чего я бы не советовал.

SonarQube позволяет вам исправлять существующие и новые проблемы понемногу и избежать сбоев сборки в течение длительного времени из-за предупреждений. Вы можете полагаться на контроль качества для получения обратной связи о качестве вашего кода и даже, если вы настаиваете, завершать сборку неудачно, если контроль качества не проходит (обратите внимание, что в больших проектах это может повлиять на время сборки).

Если ваши сборки должны завершиться ошибкой из-за предупреждений компилятора (обратите внимание, что SonarQube не собирает стандартные предупреждения компилятора, а только результаты анализаторов Roslyn), я бы рекомендовал создать отдельное задание сборки для анализа. Таким образом, вы получите лучшее из обоих миров — отслеживание проблем в SonarQube и неудачные сборки из-за предупреждений компилятора.

person Val    schedule 01.11.2017

что вы можете сделать, это пройти

/warnaserror

в качестве параметра msbuild.exe. В Azure DevOps это не будет переопределено, и сборка прервется при первом предупреждении. Если у вас исключительно чистая кодовая база, это может стать очень сильным барьером качества.

Параметры Azure DevOps MsBuild

person Norbert Hüthmayr    schedule 03.06.2020