Задача анализа SonarQube изменяет вывод сборки

Question

При настройке среды CI в нашем определении buld у нас есть задача " Подготовка анализа SonarQube " и еще одна задача, которая создает решение.

Задача, на которой строится решение, основана на CLI dotnet ( сборка dotnet ) и получает 3 параметра: конфигурацию (выпуск), файл sln и выходные данные (выходная папка, в которой будут храниться двоичные файлы). быть спасенным). Решение содержит 2 проекта: стандартную библиотеку классов .net и библиотеку классов .net Framework 4.6.2.

Чтобы проверить CI, я создал ветвь и удалил совместимый атрибут CLS из проекта .NET Framework, надеясь, что сборка не удастся (все ошибки я воспринимаю как ошибки, мой файл набора правил входит в проект и содержит, помимо прочего, правило CA1014 о соответствии CLS).

Мое удивление состояло в том, что сборка в TFS не удастся, только если я отключу этап анализа SonarQube. Если этот шаг включен, сборка проходит, и даже если я вижу в журнале это предупреждение, сборка заканчивается успешно.

Кто-нибудь из вас знает, как решить эту проблему?

Кроме того, если это неправильный сайт, чтобы спросить об этом, предложите мне, и я перенесу вопрос.

Answer 1

Я прочитал из этой документации , и там говорится, что:

Шаг "начало" изменит вашу сборку следующим образом:

• всесуществующие анализаторы кода, на которые ссылаются ваши проекты, будут отключены, и будут выполняться только анализаторы из плагинов SonarQube
• , активный код CodeAnalysisRuleSet будет обновлен в соответствии с профилем качества SonarQube
• WarningsAsErrors будет отключен

Если процесс сборки не может допустить этих изменений, мы рекомендуем создать второе задание сборки для анализа SonarQube.

Так вот почему во время сборки с этой задачей некоторыемои правила игнорируются.

Answer 2

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

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

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

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