Пиков / КАПО
Библиотека
Как читать авторский курс и нормативные материалы

Это учебные материалы, а не заключение о соответствии конкретного продукта. Организационные модели курса отделяйте от терминов стандарта: ППК в опубликованном проекте — машиночитаемый перечень, а живой реестр его версий является практикой сопровождения. Термин OSA в разных материалах имеет разный охват. Статус и обязательность нормативного документа проверяются отдельно; проект КАПО опубликован как проект первой редакции.

П31. Пилот CodeScoring: make CMake qmake

Цель

На реальной (или тестовой) C/C++ сборке прогнать build scan агента CodeScoring и получить проверяемый результат: машинный отчёт со списком распознанных компонентов и отдельный файл unresolved-библиотек. Зачёт строится не на самом факте запуска, а на том, что вы можете предъявить три разных исхода по трём системам сборки: make, CMake и qmake — с явной отметкой, где сборка прозрачна для агента, а где библиотека не разрешилась в компонент. Это и есть момент истины пилота: SCA по исходникам у C/C++ почти всегда неполон, а build scan ловит то, что реально линкуется.

Команда или действие

Build scan агента перехватывает вызовы компилятора и линковщика во время сборки, поэтому запускается поверх вашей обычной команды сборки. Конфигурация сборки описывается в buildConfig.json (что именно собирать и какой командой), а сам прогон делается так:

# 1) Обычный build scan (агент оборачивает сборку)
./johnny scan build ./buildConfig.json \
  --output result-make.json \
  --unresolved-file unresolved-make.json \
  --branch-or-tag refs/heads/pilot \
  --commit "$(git rev-parse HEAD)"

# 2) Тот же прогон через eBPF (перехват вызовов линковщика на уровне ядра Linux)
./johnny scan build ebpf ./buildConfig.json \
  --output result-make-ebpf.json \
  --unresolved-file unresolved-make-ebpf.json

Минимальный buildConfig.json под три системы сборки (по очереди подставляйте свою цель):

{
  "build_command": "cmake -S . -B build && cmake --build build -j",
  "build_result": "./build"
}

Повторите прогон трижды, меняя build_command и имена выходных файлов:

Сборка build_command output / unresolved
make make -j result-make.json / unresolved-make.json
CMake cmake -S . -B build && cmake --build build -j result-cmake.json / unresolved-cmake.json
qmake qmake && make -j result-qmake.json / unresolved-qmake.json

Сборка должна быть полной и «чистой» Агент видит только то, что реально компилируется и линкуется в этом прогоне. Перед запуском удалите кэш сборки (rm -rf build/, make clean), иначе инкрементальная сборка пропустит часть вызовов компилятора и компоненты «исчезнут» из отчёта не по вине инструмента. qmake — главная цель пилота: по материалам поставщика make/CMake обсуждались, а qmake прямо не подтверждён, поэтому его прогон фиксируем особенно тщательно.

Что вы должны увидеть

Команда завершается с кодом возврата, который и есть первый машинный сигнал результата:

Проверьте код сразу:

./johnny scan build ./buildConfig.json --output result-cmake.json ; echo "exit=$?"

В result-*.json — перечень распознанных компонентов с координатами. Ориентир по содержанию (структура, не дословный дамп):

{
  "components": [
    {
      "name": "zlib",
      "version": "1.2.13",
      "purl": "pkg:generic/zlib@1.2.13",
      "evidence": "linker",
      "scope": "required"
    },
    {
      "name": "openssl",
      "version": "3.0.11",
      "purl": "pkg:deb/debian/libssl3@3.0.11"
    }
  ]
}

В unresolved-*.json — то, что агент увидел при линковке, но не смог сопоставить с компонентом (внутренний форк, vendored-исходник, приватная .a/.so без метаданных):

{
  "unresolved": [
    { "path": "/opt/src/third_party/libfoo.a", "reason": "no metadata / no PURL" }
  ]
}

Ориентир по числу: на честной C/C++ сборке unresolved почти никогда не пуст. Пустой unresolved на legacy-проекте — повод не радоваться, а перепроверить, что сборка была полной. Сравните три прогона: число компонентов и unresolved у make/CMake/qmake должно различаться — это и есть данные для протокола.

Если не получилось

Критерий зачёта

Предъявить преподавателю три пары файлов (result-* + unresolved-*) по make, CMake и qmake с зафиксированными кодами возврата, плюс короткий вывод (3–5 строк): где сборка прозрачна, где агент потерял компоненты, и какой режим (scan build или scan build ebpf) реально отработал в вашей среде. Минимум один компонент в unresolved должен быть разобран до решения (опознан вручную либо отправлен в worklist). Решение по гейту — manual: на основании результатов сформулировать, можно ли блокировать сборку автоматически или пока только предупреждать.

Нормативная связка