Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 21
На хабре публиковалась статья: Отчёт PVS-Studio теперь в Html формате. Возможно, мы совместно можем доработать существующие форматы.
Спасибо, что более подробно описали ваш сценарий использования.
API для разбора C++ и C# проектов достаточно существенно различаются, при этом, т.к. C# анализатор разрабатывался позже, он в целом использует более «новые» API. Для C++ мы также переводили значительную часть функционала на новые API, но некоторый legacy-код ещё остаётся + не для всего новые подходы работают, к сожалению.
Нам потребуется какое-то время, чтобы проверить все места, где регистр может портиться, и понять, насколько эти места остаются критичными (к сожалению, нет просто одного места, где мы «портим» путь). Также, изменение текущего поведения может задеть некоторые другие места, где ожидается как-раз регистро-независимый путь, например, при наложении фильтров на проверяемые файлы или результаты анализа, при запуске анализа на Windows, что потребует дополнительного тестирования.
Я свяжусь с вами, когда ситуация с этим вопросом станет более понятной.
На самом деле, мы обычно всё-таки не рекомендуем нашим пользователям завязываться на формат xml отчёта ) Дело в том, что этот формат является представлением сериализованного объекта, завязанного на наш UI и в будущем, особенно в случае потенциальных серьёзных переработок UI компонентов, этот формат может поменяться.
Мы рекомендуем использовать одну из наших утилит для трансформации лога в один из стандартных форматов, таких как csv, html, plain text, и работать уже дальше с ними.
На письмо в техподдержку я получил ответ, что такое поведение обусловлено внешним API, но непонятно, почему оно такое избирательное и касается только C++, и не касается C#.
API для разбора C++ и C# проектов достаточно существенно различаются, при этом, т.к. C# анализатор разрабатывался позже, он в целом использует более «новые» API. Для C++ мы также переводили значительную часть функционала на новые API, но некоторый legacy-код ещё остаётся + не для всего новые подходы работают, к сожалению.
Нам потребуется какое-то время, чтобы проверить все места, где регистр может портиться, и понять, насколько эти места остаются критичными (к сожалению, нет просто одного места, где мы «портим» путь). Также, изменение текущего поведения может задеть некоторые другие места, где ожидается как-раз регистро-независимый путь, например, при наложении фильтров на проверяемые файлы или результаты анализа, при запуске анализа на Windows, что потребует дополнительного тестирования.
Я свяжусь с вами, когда ситуация с этим вопросом станет более понятной.
Отчёт — файл с расширением .plog, представляет собой обычный XML-файл. Схема документа встроена, поэтому никаких неожиданностей по выходному формату быть не может. ПО крайней мере пока разработчики схему не поменяют, но не будем рассматривать этот вариант.
На самом деле, мы обычно всё-таки не рекомендуем нашим пользователям завязываться на формат xml отчёта ) Дело в том, что этот формат является представлением сериализованного объекта, завязанного на наш UI и в будущем, особенно в случае потенциальных серьёзных переработок UI компонентов, этот формат может поменяться.
Мы рекомендуем использовать одну из наших утилит для трансформации лога в один из стандартных форматов, таких как csv, html, plain text, и работать уже дальше с ними.
Спасибо за ответ. Ситуация стала более ясной, чем было описано в письме.
Вот только про XML весьма жаль: очень уж удобно HTML нужного вида делать из XML. Надеюсь, этот формат когда-нибудь появится в списке «официальных» выходных форматов.
Вот только про XML весьма жаль: очень уж удобно HTML нужного вида делать из XML. Надеюсь, этот формат когда-нибудь появится в списке «официальных» выходных форматов.
Вот только про XML весьма жаль: очень уж удобно HTML нужного вида делать из XML. Надеюсь, этот формат когда-нибудь появится в списке «официальных» выходных форматов.
Возможно в более простом виде — в текущем XML слишком много legacy-«мусора» для обратной совместимости, и лишних деталей. Возможно, это будет Json. Наш linux-конвертер уже умеет сохранять подобный более простой формат, но там может не оказаться всего, что вам нужно, т.к. он делался для несколько других целей + на Windows его может быть неудобно использовать с plog'ом.
У нас сейчас, в обозримой перспективе, нет планов отказываться или кардинально менять формат лога MSBuild анализатора, поэтому пока-что можно не переживать по этому поводу )
Разобрались с этой ситуацией — MSBuild API оказались здесь не при чём — там регистр не теряется, и всё уже делается правильно. Проблема в препроцессоре Visual C++ (cl.exe), который портит пути в препроцессированном файле. Анализатор, соответственно, выдаёт уже такие «испорченные» пути.
Мы попробуем сделать для этой ситуации workaround, попытавшись восстановить путь с помощью ряда WinAPI вызовов (такое уже делается в одной из наших утилит). Надеюсь, получится включить эту правку в предстоящий в октябре релиз.
Мы попробуем сделать для этой ситуации workaround, попытавшись восстановить путь с помощью ряда WinAPI вызовов (такое уже делается в одной из наших утилит). Надеюсь, получится включить эту правку в предстоящий в октябре релиз.
Низкий поклон!
А вот и релиз 6.26 с правками.
А почему не захотели конвертировать во что-то, что можно отображать прямо в Jenkins? Например Warnings Plugin + Analysis Collector Plugin. Там вроде легко парсинг из xml настраивается. И исходники подсветить можно:
wiki.jenkins.io/display/JENKINS/Static+Code+Analysis+Plug-ins#StaticCodeAnalysisPlug-ins-source
Плюс можно «глубже» в пайплайн встраивать, например health-check настраивать:
wiki.jenkins.io/display/JENKINS/Static+Code+Analysis+Plug-ins#StaticCodeAnalysisPlug-ins-source
Плюс можно «глубже» в пайплайн встраивать, например health-check настраивать:
warnings([
canComputeNew: false,
canResolveRelativePaths: false,
defaultEncoding: '',
excludePattern: '',
healthy: '',
includePattern: '',
messagesPattern: '',
parserConfigurations: [
[
parserName: 'PyLint',
pattern: 'reports/flake8.report'
],
[
parserName: 'JSLint',
pattern: 'reports/jshint.xml'
]
],
unHealthy: ''
])
step([
$class: 'AnalysisPublisher',
defaultEncoding: '',
failedNewHigh: '0',
failedNewLow: '5',
failedNewNormal: '0',
failedTotalHigh: '0',
failedTotalLow: '50',
failedTotalNormal: '32',
healthy: '0',
unHealthy: '200',
unstableTotalLow: '40',
unstableTotalNormal: '33',
useStableBuildAsReference: true
])
Потому что не знали. Спасибо, посмотрим.
А зачем это в дженкинс тянуть когда есть sonarqube который умеет и git blame и на почту уведомления и статистику и навигацию по коду и варнинги компайлеров и сообщения валгринда и т.д. и т.п.?
Плагин pvs для sq работает замечательно.
Плагин pvs для sq работает замечательно.
Основная идея в том, что лучше использовать готовый инструмент умеющий отображать и код с ошибками, и статистику. Лично я sonarqube так и не пользовался до сих пор, поэтому написал про то что знаю.
Резонный вопрос, если есть настроенный и работающий Jenkins, то зачем еще sonarqube?
Уточните, пожалуйста, версию SQ (например 7.3 Community).
И что делать людям, которые пользуются PVS бесплатно?
И что делать людям, которые пользуются PVS бесплатно?
У нас 7.0 коммьюнити. pvs стоит не сильно дороже, чем коммерческий cpp плагин от sonarsource.
SQ CPP коммьюнити плагин работает замечательно.
Если у вас pvs бесплатно и плагина вам не полагается — мессаги pvs можно втянуть как мессаги компайлера.
SQ CPP коммьюнити плагин работает замечательно.
Если у вас pvs бесплатно и плагина вам не полагается — мессаги pvs можно втянуть как мессаги компайлера.
btw мы мессаги pvs комментариями в геррит гоним на изменения +-Х строк.
а вся картина и изменения в sq лежит.
и то и то дженкинс запускает.
а вся картина и изменения в sq лежит.
и то и то дженкинс запускает.
Но для того, чтобы это всё работало, необходима поддержка коротких путей как минимум на том диске, где ведётся анализ. Для этого в реестре по пути HKLM\SYSTEM\CurrentControlSet\Control\FileSystem необходимо установить параметр NtfsDisable8dot3NameCreation (DWORD) в значение, разрешающее сохранение коротких имён файлов. Подробнее — в MSDN.
Запрет по умолчанию на короткие имена нужно для увеличения скорости работы NTFS.
Можно либо поставить значение 0 и не заморачиваться, либо 3, если задачи CI выполняются в профиле пользователя на системном разделе или где-то в другом месте на системном разделе, либо в 2 и выполнить команду fsutil 8dot3name set Z: 0 (свой диск вместо Z:), где будет развёрнуто рабочее пространство CI (к RAM-дискам тоже относится, к слову).
В релизе 6.26 мы поменяли алгоритм, использовавшийся для восстановления регистров путей, поэтому теперь описанного выше ограничения на необходимость поддержки 8.3 путей у раздела больше нет.
Я очень сильно извиняюсь, что поднимаю сравнительно старую публикацию, но я решил это сделать, взвесив за и против. С одной стороны, мой вопрос определённо не стоит того, чтобы писать даже коротенькую заметочку, с другой стороны, обсуждение может быть интересно не только мне, а этот пост хоть как-то коррелирует с нужной мне темой.
В PVS Studio есть определённый класс диагностик, которые не выявляют собственно ошибок, но полезны с диагностической (простите за тавтологию) точки зрения. Например, вот такая:
www.viva64.com/ru/w/V122 — Memsize type is used in the struct/class
Возникает когда в структуре есть элемент, который может вызвать несовместимость бинарного представления структур на разных платформах
Или такая: www.viva64.com/en/w/V206 — Explicit conversion from 'XXX' to 'YYY'
Собственно, вопрос следующий: а есть ли где-то полный список таких «диагностик без ошибок», чтобы встроить в свой CI, сформировав отдельный список (или вообще скрыв их), чтобы они не мешались среди «нормальных» предупреждений?
Про то, чтобы выделить их в отдельную категорию и встроить такой отдельный список в среду разработки я даже не упоминаю.
В PVS Studio есть определённый класс диагностик, которые не выявляют собственно ошибок, но полезны с диагностической (простите за тавтологию) точки зрения. Например, вот такая:
www.viva64.com/ru/w/V122 — Memsize type is used in the struct/class
Возникает когда в структуре есть элемент, который может вызвать несовместимость бинарного представления структур на разных платформах
Или такая: www.viva64.com/en/w/V206 — Explicit conversion from 'XXX' to 'YYY'
Собственно, вопрос следующий: а есть ли где-то полный список таких «диагностик без ошибок», чтобы встроить в свой CI, сформировав отдельный список (или вообще скрыв их), чтобы они не мешались среди «нормальных» предупреждений?
Про то, чтобы выделить их в отдельную категорию и встроить такой отдельный список в среду разработки я даже не упоминаю.
Такого списка нет. PVS-Studio ориентирован на поиск именно ошибок, а не запахов кода. И почти всё, что он находит, при тех или иных условиях может быть ошибкой. Подробнее наш подход изложен здесь в главах «Теоретическая справка» и «Ложные срабатывания и уровни достоверности».
Например, V122 при неблагоприятном стечении обстоятельств, может стать проблемой при переносе кода с 32-битной на 64-битную систему. Что можно сделать? Если подобные структуры в вашем проекте не сохраняются в бинарном виде в файлы или куда-то ещё, то просто отключите диагностику V122.
Примечание. 64-битные диагностики (к которым как раз относится V122 и V206) являются шумными по своей природе и с этим, к сожалению, ничего нельзя сделать. Поэтому мы рекомендуем включать этот набор диагностик, как и MISRA, только в том случае, если есть чёткое понимание как с этим работать и что хочется найти.
Для начала отключите всё, кроме предупреждений общего назначения (GA) и работайте только с GA. И только если станет скучно или появится необходимость, стоит обратить внимание на другие наборы диагностик.
P.S. Выше был обобщенный ответ. Я просто хочу предостеречь читателей статей от попытки включить больше диагностик. А то как в анекдоте скоро будет «Доктор, я включаю MISRA, и мне больно» :). Что-же касается конкретного проекта, то мы можем помочь конкретными рекомендациями по настройкам. Предлагаю переместить общение в почту. Спасибо за интересную тему, затронутую в комментарии.
Например, V122 при неблагоприятном стечении обстоятельств, может стать проблемой при переносе кода с 32-битной на 64-битную систему. Что можно сделать? Если подобные структуры в вашем проекте не сохраняются в бинарном виде в файлы или куда-то ещё, то просто отключите диагностику V122.
Примечание. 64-битные диагностики (к которым как раз относится V122 и V206) являются шумными по своей природе и с этим, к сожалению, ничего нельзя сделать. Поэтому мы рекомендуем включать этот набор диагностик, как и MISRA, только в том случае, если есть чёткое понимание как с этим работать и что хочется найти.
Для начала отключите всё, кроме предупреждений общего назначения (GA) и работайте только с GA. И только если станет скучно или появится необходимость, стоит обратить внимание на другие наборы диагностик.
P.S. Выше был обобщенный ответ. Я просто хочу предостеречь читателей статей от попытки включить больше диагностик. А то как в анекдоте скоро будет «Доктор, я включаю MISRA, и мне больно» :). Что-же касается конкретного проекта, то мы можем помочь конкретными рекомендациями по настройкам. Предлагаю переместить общение в почту. Спасибо за интересную тему, затронутую в комментарии.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Короткая заметочка про PVS Studio в CI (и чего не хватает)