Pull to refresh
27
0
Алексей Говоров @MrROBUST

Пользователь

Send message
Проблема в том, что монитор стоит в сторонке, и непосредственно сборкой не управляет. Только смотрит какие процессы компиляции запускаются.
Отсюда идут проблемы прошлой реализации. Можно не успеть подключиться к моменту старта сборки, пропустить часть порождённых процессов и упустить соответствующие исходные файлы.
В текущей схеме админские права не влияют на процесс отслеживания. Просто позволяют прописаться в реестр, чтобы поставить «барьер». Тогда стартующие процессы сами придут к нам в руки. Собственно последующая сборка выполняется от того пользователя, который её запустил. Без оглядки на сервер мониторинга.

Как сделать свой отладчик для трассировки порожденных процессов я пока не разбирался. Это конечно может помочь в будущем сделать трассировщик. Но в нём хочется обойтись без повышенных прав, и грубых манипуляций со сборочной системой (типа подмены бинарников компилятора), и лишних действий со стороны пользователя.
Command Line

Вот найти кто пишет аргументы командной строки, не получилось. Не подскажете в каком оно провайдере есть? Microsoft-Windows-Kernel-Process не подошёл. А еще желательно собрать все переменные окружения.

При работе чрез систему событий есть и другая проблема. Компилятор может работать не только через аргументы командной строки, но и через временные respose-файлы. В этом случае можно также не успеть прочитать файл, чтобы извлечь из него параметры запуска.
Когда есть возможность перехватить запуск процесса, получится успеть сделать все что потребуется.
Не, ну зачем так велосипедить, внедряя свою DLL в каждый процесс системы, на вирус похоже )))

Оно не так работает. Хотя на мой взгляд это было бы лучшим решением. Только внедряясь не в каждый процесс системы, а исключительно в процесс сборки.

Сейчас пишется статья, которая подробно описывает работу новой реализации перехвата процессов
спойлер
через Image File Execution Options

и зачем вообще такие танцы с бубном. И почему ETW не подходит.
Спасибо и вам за такой интересный проект и развернутый ответ!
Понятия «Артефакты анализа» как такового у нас нет, но возможность проверки изменений проектов есть. Этот момент подробно описан здесь.
Вкратце:
Если работаете под Windows в Visual Studio, в плагине можно включить Analysis after Build (Modified Files Only).
Кроме того, возможно отследить какие файлы перекомпилируются при помощи утилиты Compiler Monitoring. После чего запускается анализ на только перекомпилированных (то есть в свою очередь измененных) файлах.
Если анализ проводится под Linux/macOS, то существует инкрементальный анализ, который отслеживает изменившиеся файлы.
pvs-studio-analyzer analyze ... --incremental ...
Так же, если известен список измененных файлов (например, из системы контроля версий), можно передать файл со списком путей к этим файлам на анализ консольным утилитам.
Windows: PVS-Studio_Cmd ... -f files.txt
Linux/macOS: pvs-studio-analyzer analyze --source-files files.txt
PlatformIO на Windows распаковывает PVS-Studio в
%USERPROFILE%\.platformio\packages\tool-pvs-studio
Чтобы сгенерировать файл лицензии там нужно вызвать утилиту CompilerCommandsAnalyzer:
CompilerCommandsAnalyzer.exe credentials NAME XXXX-XXXX-XXXX-XXXX
Полученный лицензионный файл будет размещен по пути %APPDATA%\PVS-Studio\PVS-Studio.lic, который PlatformIO использует по умолчанию.
При необходимости можно указать другой путь параметром '--lic-file' в конфигурационном файле проекта (platformio.ini)
Подробнее о параметрах написано в документации PlatformIO

Для Linux лицензионный файл генерируется командой: pvs-studio-analyzer credentials NAME XXXX-XXXX-XXXX-XXXX
Подробнее здесь.

Information

Rating
Does not participate
Registered
Activity