ccws
1.0.0
| Statut de CI |
|---|
CCWS est un environnement de développement pour ROS, qui intègre les fonctionnalités des espaces de travail catkin traditionnels et des pipelines CI afin de faciliter la compilation (croix), les tests, la liaison, la documentation et la génération de packages binaires. Il est destiné à être utilisé à la fois comme une épine dorsale CI / CD et un environnement de travail pour les développeurs. Notez que CCWS n'est pas destiné à être une solution complète, mais plutôt une base pour le développement d'un flux de travail spécifique au fournisseur.
CCWS est la version ROS agnostique et devrait fonctionner dans la plupart des cas pour ROS1 et ROS2.
Profils de construction - Ensembles de configurations pour le processus de construction, par exemple, la chaîne d'outils CMake, la configuration COLCON, les variables d'environnement, etc. Les profils ne sont pas en conflit les uns avec les autres et peuvent être utilisés en parallèle sans utiliser de clones séparés de l'espace de travail et des packages.
Profils d'exécution - Mixins de coquille simples destinés à modifier l'environnement du temps d'exécution, par exemple, exécuter les nœuds dans valgrind , modifier la manipulation du crash du nœud, etc.
Un certain nombre de fonctionnalités implémentées via des profils de construction:
Compilation croisée à plusieurs plates-formes communes.
Génération de documentation pour l'ensemble de l'espace de travail ou des packages sélectionnés à l'aide doxygen , similaires à https://github.com/mikepurvis/catkin_tools_document.
Liant avec clang-tidy et scan_build .
Divers vérifications statiques comme dans https://github.com/sscpac/statick, en particulier:
cppcheckcatkin_lint https://github.com/fkie/catkin_lintyamllintshellcheckGénération binaire de packages Debian.
Modèle de package qui montre comment utiliser certaines des fonctionnalités.
Le nombre de travaux parallèles peut être sélectionné en fonction de la RAM disponible au lieu des noyaux de processeur, car la RAM est susceptible d'être le facteur limitant.
Basé entièrement sur les scripts make et de shell. Tous les scripts et configurations sont conservés dans l'espace de travail et faciles à ajuster pour des besoins spécifiques.
Les configurations de profil sont situées dans ccws/profiles/build , le sous-répertoire common contient des paramètres par défaut, qui peuvent être remplacés par des profils spécifiques:
reldebug - Compiler par défaut, le type de build cmake est RelWithDebInfoscan_build - vérifications statiques avec scan_build et clang-tidy . Les paramètres clang-tidy sont définis dans CMake Toolchain et doivent être activés dans les packages comme indiqué dans le modèle de package CMakeLists . Ce profil utilise également le compilateur clang .thread_sanitizer - Compilation avec un désinfectant en thread.addr_undef_sanitizers - Compilation avec l'adresse et les désinfectants de comportement non définis.static_checks - Static Checkers et leur configuration.doxygen - Doxygen et sa configuration.cross_raspberry_pi - Compilation croisée pour Raspberry Pi.cross_jetson_xavier - Compilation croisée pour Jetson xavier.cross_jetson_nano - Compilation croisée pour Jetson Nano.clangd - collectionne des commandes de compilation pour un BASE_BUILD_PROFILE donné et génère un fichier de configuration Clangd dans la racine de l'espace de travail.deb - Debian Package Génération (voir ci-dessous). Profils d'exécution Définir les variables d'environnement qui peuvent être utilisées dans les scripts de lancement pour modifier le comportement du temps d'exécution, comme démontré dans ccws/pkg_template/catkin/launch/bringup.launch , les profils actuellement disponibles sont:
common - un ensemble de paramètres ROS communs, par exemple, ROS_HOME , il est automatiquement inclus dans les packages binaires.test - Définit la variable CCWS_NODE_CRASH_ACTION de sorte que les nœuds qui le respectent deviennent required , c'est-à-dire la terminaison de ces nœuds entraîneraient un crash des scripts de test et peuvent donc être facilement détectés.valgrind - Définit CCWS_NODE_LAUNCH_PREFIX sur valgrind et certaines variables qui contrôlent le comportement de valgrind .core_pattern - Définit le modèle Core pour enregistrer les fichiers Core dans le répertoire Artefacts.address_sanitizer - Assistance pour le profil addr_undef_sanitizers . Les profils d'exécution n'ont aucun effet sur le processus de construction et sont pris en compte dans les cibles *test* ou les packages Debian. Le profil d'exécution test est toujours utilisé dans les tests et des profils supplémentaires peuvent être fournis avec EXEC_PROFILE="<profile1> <profile2>" . Ces cibles chargent des profils à l'aide du script setup.bash situé dans le dossier racine de CCWS , qui peut également être utilisé manuellement, par exemple, source setup.bash [<build_profile> [<exec_profile1> ...]] . Notez que le script de configuration comprend toujours un profil common et utilise le profil d'exécution test si aucun autre profil d'exécution n'est spécifié.
Les dépendances peuvent être installées à l'aide de make bp_install_build BUILD_PROFILE=<profile> , qui va installer les outils suivants et les dépendances spécifiques au profil:
colconyq - https://github.com/asherikov/wshandlercmakeccache - Peut être désactivé dans les bandes d'outils CMakewget Voir .ccws/test_main.mk pour les conseils d'utilisation des commandes.
make/config.mk , les paramètres disponibles peuvent être trouvés dans la section supérieure de Makefile .make bp_install_build BUILD_PROFILE=<profile> Cibles, les profils de compilation croisée nécessiteraient des étapes supplémentaires comme décrit ci-dessous. Dans certains environnements minimalistes, vous devrez peut-être exécuter ./ccws/scripts/bootstrap.sh avant d'utiliser la cible bp_install_build afin d'installer make et d'autres utils.src , ou créez un nouveau à l'aide de make new PKG=<pkg> . make build PKG="<pkg>" où <pkg> est un ou plusieurs noms de packages séparés d'espace.make <pkg> - Un raccourci pour make build , mais <pkg> peut être une sous-chaîne du nom du package. Tous les packages correspondant à la sous-chaîne donnée seront construits.JOBS=X .make build PKG=<pkg> BUILD_PROFILE=scan_build remplace le profil par défaut. setup.bash <profile> pour pouvoir utiliser des packages. Les scripts de configuration générés par colcon peuvent également être utilisés directement, par exemple, install/<profile>/local_setup.sh , mais dans ce cas, certaines fonctionnalités CCWS ne seront pas disponibles. make test PKG=<pkg> TEST avec colcon , ou make wstest pour tester tout.make ctest PKG=<pkg> contourner colcon et exécutez ctest directement ou make wsctest pour tester tous. make BUILD_PROFILE=doxygen , firefox artifacts/doxygen/index.html CCWS adopte une approche quelque peu rare de la génération de packages binaires qui est un terrain d'entente entre les conteneurs traditionnels ROS (1 package = 1 deb) et Docker: tous les packages construits dans l'espace de travail sont emballés ensemble en un seul `` superpackage '' debian. Contrairement à bloom CCWS génère d'abord des packages binaires au lieu de générer des packages source.
La génération de packages binaires est implémentée en tant que mélange de profil de build qui peut être superposée sur un profil de build arbitraire: make <pkg> BUILD_PROFILE=deb BASE_BUILD_PROFILE=reldebug .
L'approche CCWS présente un certain nombre d'avantages:
Les problèmes de compatibilité binaire sont minimisés par rapport à l'approche traditionnelle des ROS:
Pas besoin de s'inquiéter des compatibilités entre plusieurs packages binaires autonomes et d'effectuer des contrôles ABI;
Si les packages ROS de base sont inclus, il est également possible d'éviter les incompatibilités binaires entre les synchronisation de la même version de ROS (celles-ci se produisent réellement).
La gestion du référentiel de packages peut être plus susmentionnée par rapport aux ROS en ce qui concerne les balises, les versions, les sous-modules GIT, etc., par exemple, il n'est pas nécessaire de maintenir des référentiels pour tous les packages.
Les «superpackages» Debian sont plus faciles à gérer que les packages autonomes et les conteneurs Docker, par exemple, ils peuvent être générés par les développeurs à partir de leurs branches de travail et facilement copiés et installés sur la cible.
Les forfaits Debian présentent certains avantages par rapport aux conteneurs Docker en général:
Zéro surcharge pendant l'exécution.
Accès simple au matériel.
Installation facile des services système, des règles UDEV, des configurations, etc.
Différentes versions de packages binaires peuvent être installées simultanément, si elles sont construites à l'aide de différents paramètres VERSION .
Généralement, il est nécessaire d'installer des packages sur la racine du système de fichiers pendant la compilation afin d'obtenir tous les chemins corrects dans les fichiers catkin cmake et d'installer correctement les fichiers système. CCWS évite cela en utilisant proot similaire aux profils de compilation croisée.
Ici <profile> signifie cross_raspberry_pi , cross_jetson_xavier , cross_jetson_nano . La compilation croisée que les cibles peuvent être trouvées dans ccws/make/cross.mk et ccws/profiles/<profile>/targets.mk
Remarque sur cross_jetson_xavier et cross_jetson_nano : Ces profils nécessitent une mélodique Ubuntu 18.04 / ROS et installer nvcc , vous pouvez le faire dans un conteneur.
Le flux de travail général est documenté ci-dessous, pour plus de détails techniques, voir ccws/doc/cross-compilation.md et CCWS CI Test dans .ccws/test_cross.mk :
make bp_install_build BUILD_PROFILE=<profile>cross_raspberry_pi - bp_install_build Target télécharge automatiquement l'image standard;cross_jetson_xavier , cross_jetson_nano - CCWS n'obtient pas ces images automatiquement, vous devez manualy copier l'image de partition système en ccws/profiles/cross_jetson_xavier/system.img .make wsinit REPOS="https://github.com/asherikov/staticoma.git"make dep_to_repolist ROS_DISTRO=melodic , ou un package spécifique make dep_to_repolist PKG=<pkg> ROS_DISTRO=melodic ;make wsupdate .make cross_install PKG=staticoma BUILD_PROFILE=<profile> ROS_DISTRO=<distro>make cross_mount BUILD_PROFILE=<profile>make staticoma BUILD_PROFILE=<profile> ou build et générer du package deb make deb PKG=staticoma BUILD_PROFILE=<profile>make cross_umount BUILD_PROFILE=<profile>CCWS Docker Une image Docker avec CCWS et dépendances préinstallées est disponible pour les tests, mais il est recommandé de créer une image sur mesure à l'aide de ccws/examples/Dockerfile à titre d'exemple.
L'image peut être utilisée de la manière suivante:
docker pull asherikov/ccwsmkdir tmp_ws # Sources, construire, installer, le cache ira icidocker run --rm -ti -v ./tmp_ws:/ccws/workspace asherikov/ccws bashmake wsinit REPOS="https://github.com/asherikov/qpmad.git"...CCWS La fonctionnalité CCWS peut être étendue de plusieurs manières:
make bp_new BUILD_PROFILE=vendor_static_checks BASE_BUILD_PROFILE=static_checks , tous les profils commençant par le préfixe vendor sont ignorés par git;make des cibles peut être ajoutée en créant un fichier ccws/profiles/build/vendor/<filename>.mk ;cmake commun peut être ajouté à ccws/profiles/build/vendor/toolchain_suffix.cmake . Fauteur de segmentation pendant la compilation croisée ou les conteneurs Docker Indside de Debian Package (tous deux nécessitent proot ): vraisemblablement en raison de la fonction seccomp Linux, qui peut être désactivée avec --security-opt seccomp:unconfined . Désactivation seccomp pour proot avec PROOT_NO_SECCOMP=1 semble être inutile.
Programmes compilés avec des désinfectants ( addr_undef_sanitizers ou des profils de construction thread_sanitizer ) Output 2: AddressSanitizer:DEADLYSIGNAL ou FATAL: ThreadSanitizer: unexpected memory mapping lors de l'exécution: la raison est resserré la sécurité de la mémoire avec ASLR (Address Space Randomisation) dans les grains linux modernes, voir Google / Sanitizers # 1614. Le problème peut être atténué en définissant sudo sysctl vm.mmap_rnd_bits=28 .
Certains des packages de noyau ROS2 ne peuvent pas être construits avec CCWS en raison d'une mauvaise utilisation de CMake, par exemple, voir Ament / Google_Benchmark_Vendor # 17.
proot Segfault lors de la construction sur ARM64 à Ubuntu 22, par exemple, tout en construisant des forfaits Debian. La nouvelle version de proot doit être utilisée, voir Proot-Me / Proot # 312.
github Action qui couvre certaines fonctionnalités CCWS .ccache par https://github.com/mbitsnbites/buildcache.clang-tidy .scan_build https://github.com/ericsson/codechecker avec des chèques supplémentaires et de la mise en cache.dpkg-deb .catkin_make .guestfs est trop lent pour être pratique.valgrind , gcc ne le prend pas en charge actuellement.valgrind - un cas exagéré dans le cas général.CodeQL (https://github.com/github/codeql).
