ccws
1.0.0
| Estado de CI |
|---|
CCWS es un entorno de desarrollo para ROS, que integra la funcionalidad de los espacios de trabajo tradicionales catkin y las tuberías de CI para facilitar la compilación (trans-), las pruebas, las pelusas, la documentación y la generación de paquetes binarios. Está destinado a ser utilizado tanto como una columna vertebral CI/CD como un entorno de trabajo para los desarrolladores. Tenga en cuenta que CCWS no pretende ser una solución completa, sino más bien una base para el desarrollo de un flujo de trabajo específico del proveedor.
CCWS es la versión ROS agnóstica, y debería funcionar en la mayoría de los casos para ROS1 y ROS2.
Creación de perfiles: conjuntos de configuraciones para el proceso de construcción, por ejemplo, CMake Toolchain, Colcon Configuration, Variables de entorno, etc. Los perfiles no entran en conflicto entre sí y pueden usarse en paralelo sin usar clones separados del espacio de trabajo y paquetes.
Perfiles de ejecución: mezclas de shell simples que están destinadas a modificar el entorno de tiempo de ejecución, por ejemplo, ejecutar nodos en valgrind , alterar el manejo de bloqueos del nodo, etc.
Varias características implementadas a través de perfiles de compilación:
Compilación cruzada a varias plataformas comunes.
Generación de documentación para todo el espacio de trabajo o paquetes seleccionados usando doxygen , similar a https://github.com/mikepurvis/catkin_tools_document.
Limpieza con clang-tidy y scan_build .
Varios cheques estáticos como en https://github.com/sscpac/statick, en particular:
cppcheckcatkin_lint https://github.com/fkie/catkin_lintyamllintshellcheckGeneración binaria de paquetes Debian.
Plantilla de paquete que demuestra cómo usar algunas de las características.
El número de trabajos paralelos se puede seleccionar en función de la RAM disponible en lugar de los núcleos de CPU, ya que es probable que RAM sea el factor limitante.
Basado completamente en scripts make y shell. Todos los scripts y configuraciones se mantienen en el espacio de trabajo y fáciles de ajustar para necesidades específicas.
Las configuraciones de perfil se encuentran en ccws/profiles/build , el subdirectorio common contiene parámetros predeterminados, que pueden ser anulados por perfiles específicos:
reldebug - compilador predeterminado, el tipo de compilación Cmake es RelWithDebInfoscan_build : verifica estática con scan_build y clang-tidy . Los parámetros de clang-tidy se definen en CMake Toolchain y deben habilitarse en paquetes como se muestra en la plantilla de paquete CMakeLists . Este perfil también usa el compilador clang .thread_sanitizer - Compilación con desinfectante de hilos.addr_undef_sanitizers - compilación con dirección y desinfectantes de comportamiento indefinidos.static_checks - verificadores estáticos y su configuración.doxygen - Doxygen y su configuración.cross_raspberry_pi -Compilación cruzada para Raspberry Pi.cross_jetson_xavier -Compilación cruzada para Jetson Xavier.cross_jetson_nano -Compilación cruzada para Jetson Nano.clangd : recopila comandos de compilación para una BASE_BUILD_PROFILE dada y genera un archivo de configuración de Clangd en la raíz del espacio de trabajo.deb - Generación de paquetes de Debian (ver más abajo). Los perfiles de ejecución establecen variables de entorno que se pueden usar en los scripts de lanzamiento para alterar el comportamiento del tiempo de ejecución como se demuestra en ccws/pkg_template/catkin/launch/bringup.launch , los perfiles actualmente disponibles son:
common : un conjunto de parámetros de ROS comunes, por ejemplo, ROS_HOME , se incluye automáticamente en los paquetes binarios.test : establece la variable CCWS_NODE_CRASH_ACTION para que los nodos que respeten se required , es decir, la terminación de tales nodos resultaría en un bloqueo de scripts de prueba y, por lo tanto, se puede detectar fácilmente.valgrind : establece CCWS_NODE_LAUNCH_PREFIX a valgrind y algunas variables que controlan el comportamiento de valgrind .core_pattern : establece el patrón de núcleo para guardar archivos centrales en el directorio de artefactos.address_sanitizer - Helper para el perfil de addr_undef_sanitizers . Los perfiles de ejecución no tienen efecto en el proceso de compilación y se tienen en cuenta en los objetivos *test* o los paquetes de Debian. El perfil de ejecución test siempre se usa en las pruebas y los perfiles adicionales se pueden proporcionar con EXEC_PROFILE="<profile1> <profile2>" . Estos objetivos de carga perfiles utilizando el script setup.bash ubicado en la carpeta raíz de CCWS , que también se pueden usar manualmente, por ejemplo, source setup.bash [<build_profile> [<exec_profile1> ...]] . Tenga en cuenta que el script de configuración siempre incluye el perfil common y utiliza el perfil de ejecución de test si no se especifican otros perfiles de ejecución.
Las dependencias se pueden instalar utilizando make bp_install_build BUILD_PROFILE=<profile> , que instalará las siguientes herramientas y dependencias específicas del perfil:
colconyq - https://github.com/asherikov/wshandler Dependencecmakeccache : se puede deshabilitar en CMake Toolchainswget Consulte .ccws/test_main.mk para sugerencias de uso de comandos.
make/config.mk , los parámetros disponibles se pueden encontrar en la sección superior de Makefile .make bp_install_build BUILD_PROFILE=<profile> Targets, los perfiles de compilación cruzada requerirían algunos pasos adicionales como se describe a continuación. En algunos entornos minimalistas, es posible que deba ejecutar ./ccws/scripts/bootstrap.sh antes de usar el objetivo bp_install_build para instalar make y otros Utils.src , o cree nuevos usos make new PKG=<pkg> . make build PKG="<pkg>" donde <pkg> es uno o más nombres de paquetes separados por el espacio.make <pkg> - un atajo para make build , pero <pkg> puede ser una subcadena del nombre del paquete. Se construirán todos los paquetes que coincidan con la subcadena dada.JOBS=Xmake build PKG=<pkg> BUILD_PROFILE=scan_build anula el perfil predeterminado. setup.bash <profile> para poder usar paquetes. Los scripts de configuración generados por colcon también se pueden usar directamente, por ejemplo, install/<profile>/local_setup.sh , pero en este caso algunas de la funcionalidad CCWS no estarán disponibles. make test PKG=<pkg> Prueba con colcon , o make wstest para probar todo.make ctest PKG=<pkg> bypass colcon y ejecute ctest directamente o make wsctest para probar todo. make BUILD_PROFILE=doxygen , firefox artifacts/doxygen/index.html CCWS adopta un enfoque algo poco común para la generación de paquetes binarios que es un punto medio entre ROS tradicional (1 paquete = 1 DEB) y contenedores Docker: todos los paquetes construidos en el espacio de trabajo están empacados en un solo 'superpackage' de Debian. A diferencia de bloom CCWS genera paquetes binarios directamente en lugar de generar los paquetes de origen primero.
La generación de paquetes binarios se implementa como una mezcla de perfil de compilación que se puede superponer a través de un perfil de compilación arbitraria: make <pkg> BUILD_PROFILE=deb BASE_BUILD_PROFILE=reldebug .
El enfoque CCWS tiene una serie de ventajas:
Los problemas de compatibilidad binaria se minimizan en comparación con el enfoque tradicional de ROS:
No es necesario preocuparse por las compatibilidades entre múltiples paquetes binarios independientes y realizar controles ABI;
Si se incluyen paquetes de ROS base, también es posible evitar incompatibilidades binarias entre sincronizaciones de la misma liberación de ROS (esos realmente suceden).
La gestión del repositorio de paquetes puede ser más descuidado en comparación con ROS cuando se trata de etiquetas, versiones, submódulos GIT, etc., por ejemplo, no hay necesidad de mantener los reposadores de liberación para todos los paquetes.
Los 'superpackages' de Debian son más fáciles de manejar que los paquetes independientes y los contenedores de Docker, por ejemplo, los desarrolladores pueden generar los desarrolladores de sus ramas de trabajo y ser fácilmente copiados e instalados en el objetivo.
Los paquetes de Debian tienen algunas ventajas sobre los contenedores Docker en general:
Cero sobrecarga durante la ejecución.
Acceso directo al hardware.
Instalación fácil de servicios del sistema, reglas de UDEV, configuraciones, etc.
Se pueden instalar diferentes versiones de paquetes binarios simultáneamente, si se construyen utilizando diferentes parámetros VERSION .
En general, es necesario instalar paquetes en la raíz del sistema de archivos durante la compilación para obtener todas las rutas correctas en los archivos cmake catkin e instalar correctamente archivos del sistema. CCWS evita esto usando proot de manera similar a los perfiles de compilación cruzada.
Aquí <profile> significa cross_raspberry_pi , cross_jetson_xavier , cross_jetson_nano . Los objetivos de marca de compilación cruzada se pueden encontrar en ccws/make/cross.mk y ccws/profiles/<profile>/targets.mk
Nota en cross_jetson_xavier y cross_jetson_nano : estos perfiles requieren Ubuntu 18.04 / ROS melódico e instalar nvcc , es posible que desee hacerlo en un contenedor.
El flujo de trabajo general se documenta a continuación, para obtener más detalles técnicos, consulte ccws/doc/cross-compilation.md y CCWS CI Prueba en .ccws/test_cross.mk :
make bp_install_build BUILD_PROFILE=<profile>cross_raspberry_pi - bp_install_build Target descarga automáticamente la imagen estándar;cross_jetson_xavier , cross_jetson_nano - CCWS no obtiene estas imágenes automáticamente, debe manualy Copiar imagen de partición del sistema a ccws/profiles/cross_jetson_xavier/system.img .make wsinit REPOS="https://github.com/asherikov/staticoma.git"make dep_to_repolist ROS_DISTRO=melodic , o un paquete específico 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> o construir y generar el paquete deb make deb PKG=staticoma BUILD_PROFILE=<profile>make cross_umount BUILD_PROFILE=<profile>CCWS Docker Una imagen de Docker con CCWS y dependencias preinstaladas está disponible para las pruebas, pero se recomienda construir una imagen personalizada utilizando ccws/examples/Dockerfile como ejemplo.
La imagen se puede usar de la siguiente manera:
docker pull asherikov/ccwsmkdir tmp_ws # fuentes, compilación, instalación, caché irá aquídocker run --rm -ti -v ./tmp_ws:/ccws/workspace asherikov/ccws bashmake wsinit REPOS="https://github.com/asherikov/qpmad.git"...CCWS La funcionalidad CCWS se puede extender de múltiples maneras:
make bp_new BUILD_PROFILE=vendor_static_checks BASE_BUILD_PROFILE=static_checks , todos los perfiles que comienzan con el prefijo vendor se ignoran por git;make creando un archivo ccws/profiles/build/vendor/<filename>.mk ;cmake común a ccws/profiles/build/vendor/toolchain_suffix.cmake . Falla de segmentación durante la compilación cruzada o los contenedores de Docker de la generación de paquetes de Debian (ambos requieren proot ): presumiblemente debido a la función seccomp Linux, que se puede deshabilitar con --security-opt seccomp:unconfined . Desactivar seccomp para proot con PROOT_NO_SECCOMP=1 parece ser innecesario.
Programas compilados con Sanitizers ( addr_undef_sanitizers o thread_sanitizer Build Perfiles) Salida 2: AddressSanitizer:DEADLYSIGNAL o FATAL: ThreadSanitizer: unexpected memory mapping cuando se ejecuta: la razón es la seguridad de la memoria ajustada con ASLR (aleatorización de diseño espacial de direcciones) en los modernos eje de Linux, ver Google/Sanitizers#1614. El problema se puede aliviar configurando sudo sysctl vm.mmap_rnd_bits=28 .
Algunos de los paquetes centrales de ROS2 no se pueden construir con CCWS debido al mal uso de CMake, por ejemplo, consulte AMent/Google_Benchmark_Vendor#17.
proot segfault mientras se construye en ARM64 en Ubuntu 22, por ejemplo, mientras construye paquetes Debian. Se debe utilizar la versión más nueva de proot , ver Proot-Me/Proot#312.
github que cubre parte de la funcionalidad CCWS .ccache con https://github.com/mbitsnbites/buildcache.clang-tidy .scan_build https://github.com/ericsson/codechecker con cheques adicionales y almacenamiento en caché.dpkg-deb .catkin_make .guestfs son demasiado lentos para ser prácticos.valgrind , gcc no lo admite actualmente.valgrind , sin embargo, una exageración en el caso general.CodeQL (https://github.com/github/codeql).
