Мы используем SonarQube 5.6.6 (LTS) с плагином SonarC# версии 6.5.0.3766 и обновлением 2 TFS 2017 (плагин SonarQube v. 3.0.2).
Мы постоянно видим, что проблемы, которые ранее были помечены как решенные (не исправить), снова открываются. Мой вопрос: почему SonarQube ведет себя таким образом?
Эта проблема также упоминается в ряде различных сообщений (1,2,3) в StackOverflow, но без основной причины или решения. Ссылка 3 также указывает, что это проблема с использованием SonarQube 6.2.
Мне любопытно, связано ли это с неправильной конфигурацией с нашей стороны или с интегрированной частью SonarQube?
Наш сервер SonarQube работает на сервере Win 2012 R2 с серверной частью MS SQL, если это актуально?
Кроме того, мы используем TFVC для управления версиями и обвиняем плагин SCM. Если проблема была помечена как решенная (не будет исправлена), я заметил, что она выглядит как открытая как новая проблема (т. е. история недоступна).
Пример: коллега пометил проблему как решенную (не будет исправлять) в файле, который последний раз изменялся в TFVC еще в ноябре 2015 года. Однако сегодня утром проблема была помечена как открытая и назначена разработчику, который первоначально проверил код. В SonarQube нет истории о том, что проблема ранее находилась в решенном состоянии. Похоже, что это новая проблема в новом файле, а не известная проблема, которая уже решена?
Чтобы избежать странных проблем, связанных с компиляцией нашего решения C#, мы всегда полностью очищаем наше рабочее пространство перед нашей сборкой. Я не знаю, есть ли что сказать? Наши сборки также выполняются на разных сборочных машинах, поэтому я не знаю, заставит ли это SonarQube думать, что мы действительно всегда анализируем новые файлы?
Может ли использование разных машин сборки и/или определений сборки для одного и того же проекта SonarQube привести к такому поведению?
Я также видел из журналов и отчетов, что SonarQube, по-видимому, анализирует ВСЕ решение, а не только измененные файлы. Это делает наш анализ очень трудоемким и совершенно не подходящим для быстрой обратной связи. Я подозреваю, что длительный период анализа и повторное открытие вопросов связаны. Анализ проекта с примерно 280 KLOC занимает ок. 8-10 мин. в качестве фоновой задачи на сервере. Это при последующем анализе (т.е. не при первом запуске).
Связано ли это с вышеупомянутой проблемой повторного открытия сервером задач?
Как ни странно, периоды утечек работают корректно, т. е. мы правильно выявляем проблемы в пределах правильного периода утечек. Я еще не проверял это подробно, но это определенно не ВСЕ старые проблемы, о которых сообщается как об открытых в течение периода утечки. Мы видим, что старые проблемы появляются снова только в том случае, если файл, содержащий их, был изменен — это активирует все другие проблемы (из предыдущей версии или периода утечки) в этом файле.
Я не указал никаких дополнительных параметров командной строки для сканера SonarQube во время сборки, кроме плагина TFVC SCM и пути для данных покрытия. Мы используем задачу VSTEST версии 2 как в противном случае невозможно собрать покрытие кода в SonarQube при использовании TFS 2017, обновление 2 и VS 2017.
Пожалуйста, сообщите о любых дополнительных данных, которые я должен предоставить, чтобы помочь в этом. Спасибо за помощь!
