ccws

Статус CI

Введение

CCWS -это среда разработки для АФК, которая интегрирует функциональность традиционных catkin пространств и трубопроводов CI для облегчения (перекрестного) компиляции, тестирования, подлимки, документации и генерации двоичных пакетов. Он предназначен для использования как в качестве костяка CI/CD для разработчиков. Обратите внимание, что CCWS предназначен не для того, чтобы быть полным решением, а скорее основой для разработки рабочего процесса, специфичного для поставщика.

CCWS - это версия ROS Agnostic, и в большинстве случаев должна работать как для ROS1, так и для ROS2.

Функции

• Профили сборки - наборы конфигураций для процесса сборки, например, Cmake Toolchain, Colcon Configuration, переменных среды и т. Д.

• Профили выполнения - простые микшины для оболочки, которые предназначены для изменения среды времени выполнения, например, выполнения узлов в valgrind , обработки сбоя узлов и т. Д.

• Ряд функций, реализованных с помощью профилей сборки:

  • Поперечное компиляция на несколько общих платформ.

  • Генерация документации для всей рабочей области или выбранных пакетов с использованием doxygen , аналогично https://github.com/mikepurvis/catkin_tools_document.

  • Слив с clang-tidy и scan_build .

  • Различные статические проверки, как в https://github.com/sscpac/statick, в частности:

    • cppcheck
    • catkin_lint https://github.com/fkie/catkin_lint
    • yamllint
    • shellcheck

  • Двоичное поколение пакетов Debian.

• Шаблон упаковки, который демонстрирует, как использовать некоторые функции.

• Количество параллельных заданий может быть выбрано на основе доступной оперативной памяти вместо ядер процессоров, поскольку ОЗУ, вероятно, будет ограничивающим фактором.

• Основанный полностью на сценариях make и оболочки. Все сценарии и конфигурации хранятся в рабочем пространстве и легко корректируются для конкретных потребностей.

Строить профили

Конфигурации профиля расположены в ccws/profiles/build , common Suberctory содержит параметры по умолчанию, которые могут быть переопределены конкретными профилями:

• [по умолчанию] reldebug - компилятор по умолчанию, тип сборки Cmake RelWithDebInfo
• scan_build -Статические проверки с scan_build и clang-tidy . Параметры clang-tidy определены в Cmake Toolchain и должны быть включены в пакетах, как показано в шаблоне пакетов CMakeLists . В этом профиле также используется компилятор clang .
• thread_sanitizer - Компиляция с дезинфицирующим средством потока.
• addr_undef_sanitizers - Компиляция с адресами и неопределенным поведением дезинфицирует.
• static_checks - статические шашки и их конфигурация.
• doxygen - Doxygen и его конфигурация.
• cross_raspberry_pi -кросс-компиляция для Raspberry Pi.
• cross_jetson_xavier -Кросс-компиляция для Jetson Xavier.
• cross_jetson_nano -кросс-компиляция для Jetson nano.
• clangd - собирает команды компиляции для данного BASE_BUILD_PROFILE и генерирует файл конфигурации CLANGD в корне рабочей области.
• deb - Debian Package Generation (см. Ниже).

Профили исполнения

Профили выполнения устанавливают переменные среды, которые можно использовать в сценариях запуска для изменения поведения времени выполнения, как показано в ccws/pkg_template/catkin/launch/bringup.launch , доступные в настоящее время профили:

• common - набор общих параметров ROS, например, ROS_HOME , автоматически включается в двоичные пакеты.
• test - Устанавливает переменную CCWS_NODE_CRASH_ACTION для того, чтобы узлы, которые уважали ее, становятся required , то есть завершение таких узлов приведет к сбою тестовых сценариев и, таким образом, может быть легко обнаружено.
• valgrind - устанавливает CCWS_NODE_LAUNCH_PREFIX для valgrind и некоторые переменные, которые управляют поведением valgrind .
• core_pattern - Устанавливает основной шаблон для сохранения основных файлов в каталоге артефактов.
• address_sanitizer - помощник профиля addr_undef_sanitizers .

Профили выполнения не влияют на процесс сборки и принимаются во внимание в *test* Targets или Debian Packages. Профиль выполнения test всегда используется в тестах, и дополнительные профили могут быть предоставлены с помощью EXEC_PROFILE="<profile1> <profile2>" . Эти цели загружают профили с использованием скрипта setup.bash , расположенного в корневой папке CCWS , которые также можно использовать вручную, например, source setup.bash [<build_profile> [<exec_profile1> ...]] . Обратите внимание, что сценарий настройки всегда включает в себя common профиль и использует профиль выполнения test , если не указано другие профили выполнения.

Зависимости

Зависимости могут быть установлены с использованием make bp_install_build BUILD_PROFILE=<profile> , который собирается установить следующие инструменты и конкретные зависимости профиля:

• colcon
• yq - https://github.com/asherikov/wshandler -зависимость
• cmake
• ccache - может быть отключен в Cmake Toolchains
• wget

Использование

См .ccws/test_main.mk

Начальная настройка

• Переопределите специфические параметры разработчика и поставщика, добавив их в make/config.mk , доступные параметры можно найти в верхнем разделе Makefile .
• Установите зависимости, используя make bp_install_build BUILD_PROFILE=<profile> Цели, профили поперечного компиляции потребуют дополнительных шагов, как описано ниже. В некоторых минималистичных средах вам может потребоваться запустить ./ccws/scripts/bootstrap.sh перед использованием цели bp_install_build для установки make и других UTIL.
• Клонические пакеты в подкаталоге src или создайте новые, используя make new PKG=<pkg> .

Компиляция

• make build PKG="<pkg>" , где <pkg> - одно или несколько имен пакетов, разделенных пространством.
• make <pkg> - ярлык для make build , но <pkg> может быть подстрокой имени пакета. Будут построены все пакеты, соответствующие данной подстроению.
• Количество заданий может быть переопределено с помощью параметра JOBS=X .
• make build PKG=<pkg> BUILD_PROFILE=scan_build переопределять профиль по умолчанию.

Бег

• Source setup.bash <profile> Чтобы иметь возможность использовать пакеты. Настройки сценариев, сгенерированных colcon , также могут использоваться напрямую, например, install/<profile>/local_setup.sh , но в этом случае некоторые функциональности CCWS не будут доступны.

Тестирование

• make test PKG=<pkg> тест с colcon или make wstest , чтобы проверить все.
• make ctest PKG=<pkg> обход colcon и запустите ctest напрямую или make wsctest для проверки всех.

Документация

• make BUILD_PROFILE=doxygen , firefox artifacts/doxygen/index.html

Поколение пакетов Debian

Обзор

CCWS использует несколько необычный подход к генерации двоичных пакетов, который представляет собой середину между традиционными контейнерами ROS (1 пакет = 1 deb) и контейнерами Docker: все пакеты, построенные в рабочем пространстве, упакованы в один Debian 'SuperPackage'. В отличие от bloom CCWS генерирует двоичные пакеты непосредственно вместо того, чтобы сначала генерировать исходные пакеты.

Генерация двоичных пакетов реализована как профиль сборки, который можно наложить на произвольный профиль сборки: make <pkg> BUILD_PROFILE=deb BASE_BUILD_PROFILE=reldebug .

Подход CCWS имеет ряд преимуществ:

• Проблемы бинарной совместимости минимизируются по сравнению с традиционным подходом АФК:

  • Не нужно беспокоиться о совместимости между несколькими автономными бинарными пакетами и выполнять проверки ABI;

  • Если базовые пакеты ROS включены, также возможно избегать бинарной несовместимости между синхронизациями того же выпуска ROS (которые на самом деле случаются).

• Управление репозиторием пакетов может быть небрежным по сравнению с АФК, когда речь идет о тегах, версиях, подмодулях GIT и т. Д., Например, нет необходимости поддерживать репомит для всех пакетов.

• Debian 'Superpackages' легче обрабатывать, чем как автономные пакеты, так и контейнеры Docker, например, они могут генерироваться разработчиками из своих рабочих филиалов и легко скопируются и установлены на цель.

• У Debian Packages есть некоторые преимущества по сравнению с контейнерами Docker в целом:

  • Ноль накладных расходов во время исполнения.

  • Простой доступ к оборудованию.

  • Легкая установка системных служб, правил UDEV, конфигураций и т. Д.

• Различные версии двоичных пакетов могут быть установлены одновременно, если они созданы с использованием различных параметров VERSION .

Строительные пакеты

Как правило, необходимо установить пакеты в корень файловой системы во время компиляции, чтобы получить все пути прямо в файлах catkin cmake и правильно установить системные файлы. CCWS избегает этого, используя proot аналогично профилям межкомпиляции.

Кросс-компиляция

Здесь <profile> означает cross_raspberry_pi , cross_jetson_xavier , cross_jetson_nano . Крестовой компиляции Make Targets можно найти в ccws/make/cross.mk и ccws/profiles/<profile>/targets.mk

Примечание на cross_jetson_xavier и cross_jetson_nano : Эти профили требуют Ubuntu 18.04 / ROS Melodic и установить nvcc , вы можете сделать это в контейнере.

Общий рабочий процесс задокументирован ниже, для получения дополнительной технической информации см. ccws/doc/cross-compilation.md и CCWS CI-тест в .ccws/test_cross.mk :

1. Установите зависимости профиля с помощью make bp_install_build BUILD_PROFILE=<profile>
2. Получить системное изображение:
   • cross_raspberry_pi - bp_install_build Target автоматически загружает стандартное изображение;
   • cross_jetson_xavier , cross_jetson_nano - CCWS не получает этих изображений автоматически, вы должны для ручной копии ccws/profiles/cross_jetson_xavier/system.img
3. Инициализировать хранилища источников:
   • make wsinit REPOS="https://github.com/asherikov/staticoma.git"
   • [При построении всех пакетов ROS] Добавьте ROS -зависимости от всех ваших пакетов в рабочую область make dep_to_repolist ROS_DISTRO=melodic или конкретный пакет make dep_to_repolist PKG=<pkg> ROS_DISTRO=melodic ;
   • make wsupdate все пакеты.
4. Установите системные зависимости пакетов в вашем рабочем пространстве в системном изображении: make cross_install PKG=staticoma BUILD_PROFILE=<profile> ROS_DISTRO=<distro>
5. Скомпилируйте пакеты:
   • Mount sysroot с помощью make cross_mount BUILD_PROFILE=<profile>
   • Строите пакеты, например, make staticoma BUILD_PROFILE=<profile> или создайте и генерируйте Deb Package make deb PKG=staticoma BUILD_PROFILE=<profile>
   • Unmount Sysroot, когда сделано с помощью make cross_umount BUILD_PROFILE=<profile>

Использование CCWS Docker

Для тестирования доступно изображение Docker с предварительно установленным CCWS и зависимостями, но рекомендуется создать адаптированное изображение с использованием ccws/examples/Dockerfile в качестве примера.

Изображение можно использовать следующим образом:

• docker pull asherikov/ccws
• mkdir tmp_ws # Источники, сборка, установка, кэш пойдет здесь
• docker run --rm -ti -v ./tmp_ws:/ccws/workspace asherikov/ccws bash
• make wsinit REPOS="https://github.com/asherikov/qpmad.git"
• ...

Расширение CCWS

Функциональность CCWS может быть расширена несколькими способами:

• Добавляя новые профили сборки, например, make bp_new BUILD_PROFILE=vendor_static_checks BASE_BUILD_PROFILE=static_checks , все профили, начинающиеся с префикса vendor игнорируются GIT;
• добавив профили исполнения;
• make цели может быть добавлена ​​путем создания файла ccws/profiles/build/vendor/<filename>.mk ;
• Общий суффикс инструментов cmake может быть добавлен в ccws/profiles/build/vendor/toolchain_suffix.cmake .

Известные проблемы

• Неисправность сегментации во время кросс-компиляции или генерации пакетов Debian Indside Docker контейнеров (оба требуют proot ): предположительно из-за функции seccomp Linux, которая может быть отключена с помощью --security-opt seccomp:unconfined . Отключение seccomp для proot с PROOT_NO_SECCOMP=1 кажется ненужным.

• Программы, скомпилированные с дезинфицирующими средствами ( addr_undef_sanitizers или thread_sanitizer PROFIESE) Вывод 2: AddressSanitizer:DEADLYSIGNAL или FATAL: ThreadSanitizer: unexpected memory mapping при выполнении: причина - это затянутая безопасность памяти ASLR (Рандомизация расположения адреса) в современных Linux Kernels, см. Google/Sanitizers#1614. Эта проблема может быть облегчена путем установки sudo sysctl vm.mmap_rnd_bits=28 .

• Некоторые из основных пакетов ROS2 не могут быть построены с помощью CCWS из -за неправильного использования CMAKE, например, см. Ament/Google_benchmark_vendor#17.

• proot Segfault, накапливаясь на ARM64 в Ubuntu 22, например, при создании пакетов Debian. Новая версия proot должна быть использована, см. Proot-Me/Proot#312.

Связанное программное обеспечение

• https://github.com/ros-industrial/industrial_ci-ROS-специфические CI Scripts, неинтернативный, «одноразовый» дизайн, без дезинфицирующих средств, эмулированная поперечная компиляция.
• https://github.com/ros-tooling/cross_compile/-эмулированный кросс-компиляция для ROS и ROS2.
• https://github.com/hesselm/rpicross_notes - Cross Compilation для Raspberry Pi сделано по -другому.
• https://github.com/ros-tooling/action-ros-ci-действие github , которое охватывает некоторые функциональность CCWS .
• https://github.com/ros-infrastructure/ros_buildfarm, http://wiki.ros.org/buildfarm-ядро инфраструктуры упаковки ROS. Сложный, специализированный на обработке отдельных пакетов, а не рабочими пространствами, не подходит для быстрого перераспределения на поле.
• https://github.com/colcon/colcon-bundle предоставляет функциональность, аналогичную «суперпаксам», позволяющим упаковать пространство в один архив. Естественно, он не предоставляет все функции пакетов, такие как зависимости, устанавливать сценарии и т. Д. Кроме того, он не зависит от среды, похожей на Chroot для обеспечения правильных путей.

Тодо

• Fuzzing https://github.com/rosin-project/ros2_fuzz, https://github.com/sslab-gatech/robofuzz, https://github.com/aflplusplus/aflplusplus, https://github.com/google/clustrus
• Исследовать поколение пакетов отладки и разработки.
• Воспроизводимый строит https://reproducible-builds.org/.
• Замените ccache на https://github.com/mbitsnbites/buildcache.
• Интегрируйте https://github.com/oclint/oclint
• https://github.com/ejfitzgerald/clang-tidy-cache или https://github.com/mbitsnbites/buildcache можно использовать для кэширования запуска clang-tidy .
• https://github.com/mrtazz/checkmake может быть полезен для подкладки Makefile.
• Cache Cmake проверяет с помощью https://github.com/cristianadam/cmake-checks-cache, https://github.com/polysquare/cmake-forward-cache также может быть полезен.
• Оболочка форматала https://github.com/mvdan/sh.
• https://github.com/myint/cppclean может быть полезен для ненужного обнаружения заголовков, но выглядит несвежим.
• https://github.com/include-what-you-use/include-wathat-you-use
• Анализ времени построения с Clang https://github.com/aras-p/clangbuildanalyzer и/или https://github.com/jrmadsen/compile-ime-perf.
• Потенциальная замена для scan_build https://github.com/ericsson/codechecker с дополнительными проверками и кэшированием.
• https://github.com/sscpac/statick не будет использоваться, но некоторые из его Линтера могут быть интегрированы.
• Исходный код willscheck https://github.com/myint/scspell.
• https://github.com/jordansissel/fpm-универсальный двоичный генератор пакетов, потенциальная замена для dpkg-deb .
• https://github.com/git-afsantos/haros-статический анализ Ros-aware, может иметь проблемы с средами не catkin_make Build.
• https://github.com/tencent/tscancode - C ++ Статический анализ.
• https://github.com/dlu/roscompile/tree/main/roscompile - Linter для Catkin Packages.
• Используйте https://libguestfs.org/ или https://github.com/alperakcan/fuse-ext2 вместо цикла, чтобы избежать использования Sudo. Хотя в Ubuntu возникают некоторые проблемы, ошибка 759725, см. Https://libguestfs.org/guestfs-faq.1.html. guestfs слишком медленно, чтобы быть практичными.
• Поддержка распределенной компиляции с https://github.com/distcc/distcc может быть полезна.
• Добавьте профиль дезинфицирующего средства памяти в качестве альтернативы valgrind , gcc не поддерживает его в настоящее время.
• Добавить профиль покрытия кода.
• Профиль выполнения с https://github.com/yugr/libdebugme для автоматического запуска отладчика на сигнале.
• https://github.com/yugr/valgrind-peload в качестве альтернативы профилю выполнения valgrind -все же излишний в общем случае.
• Видимость символа управления и проверить с помощью https://github.com/yugr/shlibvisibilitychecker.
• Добавить профиль CodeQL (https://github.com/github/codeql).