ccws

Status do CI

Introdução

CCWS é um ambiente de desenvolvimento para a ROS, que integra a funcionalidade dos espaços de trabalho tradicionais catkin e os tubulações de IC, a fim de facilitar a compilação, teste, linhagem, documetação e geração de pacotes binários. Destina -se a ser usado como um backbone de CI/CD e um ambiente de trabalho para os desenvolvedores. Observe que CCWS não se destina a ser uma solução completa, mas uma base para o desenvolvimento de um fluxo de trabalho específico do fornecedor.

CCWS é a versão do ROS AGNOSTIC e deve trabalhar na maioria dos casos para Ros1 e ROS2.

Características

• Perfis de construção - Conjuntos de configurações para processo de construção, por exemplo, CMake Toolchain, configuração do COLCON, variáveis ​​de ambiente, etc. Os perfis não conflitam entre si e podem ser usados ​​em paralelo sem usar clones separados do espaço de trabalho e dos pacotes.

• Perfis de execução - Misturas simples de shell que se destinam a modificar o ambiente de tempo de execução, por exemplo, executar nós em valgrind , alterar o manuseio de falhas do nó, etc.

• Vários recursos implementados por meio de perfis de construção:

  • Compilação cruzada para várias plataformas comuns.

  • Geração de documentação para toda a área de trabalho ou pacotes selecionados usando doxygen , semelhante a https://github.com/mikepurvis/catkin_tools_document.

  • LING COM clang-tidy e scan_build .

  • Várias verificações estáticas como em https://github.com/sscpac/statick, em particular:

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

  • Geração binária de pacotes debian.

• Modelo de pacote que demonstra como usar alguns dos recursos.

• O número de trabalhos paralelos pode ser selecionado com base na RAM disponível em vez dos núcleos da CPU, uma vez que a RAM provavelmente será o fator limitante.

• Baseado inteiramente em scripts make e shell. Todos os scripts e configurações são mantidos no espaço de trabalho e fáceis de ajustar para necessidades específicas.

Construir perfis

As configurações de perfil estão localizadas em ccws/profiles/build , o subdiretório common contém parâmetros padrão, que podem ser superestimados por perfis específicos:

• [Padrão] reldebug - Compilador padrão, o tipo de compilação CMake está RelWithDebInfo
• scan_build -Verificações estáticas com scan_build e clang-tidy . Os parâmetros clang-tidy são definidos na Chake Toolchain e devem ser ativados em pacotes, conforme mostrado no modelo de pacote CMakeLists . Este perfil também usa o compilador clang .
• thread_sanitizer - Compilação com desinfetante para threads.
• addr_undef_sanitizers - Compilação com endereço e desinfetantes de comportamento indefinido.
• static_checks - damas estáticas e sua configuração.
• doxygen - Doxygen e sua configuração.
• cross_raspberry_pi -Compilação cruzada para Raspberry Pi.
• cross_jetson_xavier -Compilação cruzada para Jetson Xavier.
• cross_jetson_nano -Compilação cruzada para Jetson Nano.
• clangd - coleta comandos de compilação para um determinado BASE_BUILD_PROFILE e gera arquivo de configuração do CLANGD na raiz da área de trabalho.
• deb - Debian Package Generation (veja abaixo).

Perfis de execução

Perfis de execução Definir variáveis ​​de ambiente que podem ser usadas nos scripts de lançamento para alterar o comportamento do tempo de execução, conforme demonstrado em ccws/pkg_template/catkin/launch/bringup.launch , os perfis atualmente disponíveis são:

• common - um conjunto de parâmetros comuns de ROS, por exemplo, ROS_HOME , ele é automaticamente incluído em pacotes binários.
• test - Define a variável CCWS_NODE_CRASH_ACTION para que os nós que o respeitem se tornem required , ou seja, o término de tais nós resultaria em falha de scripts de teste e, portanto, pode ser facilmente detectado.
• valgrind - Define CCWS_NODE_LAUNCH_PREFIX para valgrind e algumas variáveis ​​que controlam o comportamento de valgrind .
• core_pattern - Define o padrão principal para salvar arquivos principais no diretório do artefatos.
• address_sanitizer - ajudante para addr_undef_sanitizers perfil.

Os perfis de execução não têm efeito no processo de construção e são levados em consideração em metas *test* ou pacotes de Debian. O perfil de execução test é sempre usado em testes e perfis adicionais podem ser fornecidos com EXEC_PROFILE="<profile1> <profile2>" . Esses alvos carregam perfis de carregamento usando o script setup.bash localizado na pasta raiz do CCWS , que também pode ser usada manualmente, por exemplo, source setup.bash [<build_profile> [<exec_profile1> ...]] . Observe que o script de configuração sempre inclui perfil common e usa o perfil de execução de test se nenhum outro perfil de execução for especificado.

Dependências

As dependências podem ser instaladas usando make bp_install_build BUILD_PROFILE=<profile> , que instalará as seguintes ferramentas e dependências específicas do perfil:

• colcon
• yq - https://github.com/asherikov/wshandler dependência
• cmake
• ccache - pode ser desativado nas cadeias de ferramentas cmake
• wget

Uso

Veja .ccws/test_main.mk para dicas de uso de comando.

Configuração inicial

• Substituir parâmetros específicos do desenvolvedor e do fornecedor, adicionando -os para make/config.mk , os parâmetros disponíveis podem ser encontrados na seção superior do Makefile .
• Instale as dependências usando make bp_install_build BUILD_PROFILE=<profile> Alvos, os perfis de compilação cruzada exigiriam algumas etapas extras, conforme descrito abaixo. Em alguns ambientes minimalistas, pode ser necessário executar ./ccws/scripts/bootstrap.sh antes de usar o destino bp_install_build para instalar make e outros utils.
• Pacotes de clone no subdiretório src ou crie novos usando make new PKG=<pkg> .

Compilação

• make build PKG="<pkg>" onde <pkg> é um ou mais nomes de pacotes separados por espaço.
• make <pkg> - Um atalho para make build , mas <pkg> pode ser uma substring do nome do pacote. Todos os pacotes que correspondem à substring fornecida serão construídos.
• O número de trabalhos pode ser substituído com o parâmetro JOBS=X
• make build PKG=<pkg> BUILD_PROFILE=scan_build substitui o perfil padrão.

Correndo

• Orient setup.bash <profile> Para poder usar pacotes. Os scripts de configuração gerados pelo colcon também podem ser usados ​​diretamente, por exemplo, install/<profile>/local_setup.sh , mas neste caso algumas da funcionalidade CCWS não estarão disponíveis.

Teste

• make test PKG=<pkg> Teste com colcon ou make wstest testar tudo.
• make ctest PKG=<pkg> IGRAIR colcon e RONE ctest diretamente ou make wsctest para testar tudo.

Documentação

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

Geração do Pacote Debian

Visão geral

CCWS adota uma abordagem um tanto incomum para a geração de pacotes binários, que é um meio termo entre os ROS tradicionais (1 pacote = 1 Deb) e os contêineres do Docker: Todos os pacotes construídos na área de trabalho são empacotados em um único 'superpackage' debian. Ao contrário bloom CCWS , gera pacotes binários diretamente em vez de gerar pacotes de origem primeiro.

A geração de pacotes binários é implementada como uma mistura de perfil de construção que pode ser sobreposta sobre um perfil de construção arbitrário: make <pkg> BUILD_PROFILE=deb BASE_BUILD_PROFILE=reldebug .

A abordagem CCWS tem várias vantagens:

• Os problemas de compatibilidade binária são minimizados em comparação com a abordagem tradicional da ROS:

  • Não há necessidade de se preocupar com compatibilidades entre vários pacotes binários independentes e executar verificações da ABI;

  • Se os pacotes básicos de ROS estiverem incluídos, também será possível evitar incompatibilidades binárias entre as sincronizações da mesma liberação de ROS (essas realmente acontecem).

• O gerenciamento do repositório de pacotes pode ser mais desleixado em comparação com o ROS quando se trata de tags, versões, submódulos Git, etc., por exemplo, não há necessidade de manter os repositórios de liberação para todos os pacotes.

• Os 'superpackages' do Debian são mais fáceis de manusear do que os pacotes independentes e os contêineres do Docker, por exemplo, eles podem ser gerados pelos desenvolvedores de seus ramos de trabalho e facilmente copiados e instalados no alvo.

• Os pacotes do Debian têm algumas vantagens sobre os contêineres do Docker em geral:

  • Zero sobrecarga durante a execução.

  • Acesso direto ao hardware.

  • Instalação fácil de serviços do sistema, regras UDEV, configurações, etc.

• Versões diferentes de pacotes binárias podem ser instaladas simultaneamente, se forem construídas usando diferentes parâmetros VERSION .

Pacotes de construção

Geralmente, é necessário instalar pacotes na raiz do sistema de arquivos durante a compilação para acertar todos os caminhos nos arquivos catkin cmake e instalar corretamente os arquivos do sistema. CCWS evita isso usando proot de maneira semelhante aos perfis de compilação cruzada.

Compilação cruzada

Aqui <profile> significa cross_raspberry_pi , cross_jetson_xavier , cross_jetson_nano . A compilação cruzada é que os alvos podem ser encontrados no ccws/make/cross.mk e ccws/profiles/<profile>/targets.mk

Nota em cross_jetson_xavier e cross_jetson_nano : esses perfis exigem o Ubuntu 18.04 / ROS Melodic e instalam nvcc , você pode querer fazer isso em um contêiner.

O fluxo de trabalho geral está documentado abaixo, para mais detalhes técnicos, consulte o teste ccws/doc/cross-compilation.md e CCWS CI em .ccws/test_cross.mk :

1. Instale as dependências do perfil com make bp_install_build BUILD_PROFILE=<profile>
2. Obtenha a imagem do sistema:
   • cross_raspberry_pi - bp_install_build Target baixar automaticamente a imagem padrão;
   • cross_jetson_xavier , cross_jetson_nano - CCWS não obtém essas imagens automaticamente, você precisa manualmente copiar a imagem de partição do sistema para ccws/profiles/cross_jetson_xavier/system.img .
3. Inicialize os repositórios de origem:
   • make wsinit REPOS="https://github.com/asherikov/staticoma.git"
   • [Ao criar todos os pacotes ROS] Adicione dependências de ROS de todos os seus pacotes ao espaço de trabalho, make dep_to_repolist ROS_DISTRO=melodic , ou um pacote específico make dep_to_repolist PKG=<pkg> ROS_DISTRO=melodic ;
   • buscar todos os pacotes make wsupdate .
4. Instale as dependências do sistema de pacotes em seu espaço de trabalho na imagem do sistema: make cross_install PKG=staticoma BUILD_PROFILE=<profile> ROS_DISTRO=<distro>
5. Compilar pacotes:
   • Mount Sysroot com make cross_mount BUILD_PROFILE=<profile>
   • Build Packages, por exemplo, make staticoma BUILD_PROFILE=<profile> ou construir e gerar o pacote make deb PKG=staticoma BUILD_PROFILE=<profile>
   • desmontar sysroot quando feito com make cross_umount BUILD_PROFILE=<profile>

Usando o CCWS Docker

Uma imagem do Docker com CCWS e dependências pré -instalados está disponível para teste, mas é recomendável construir uma imagem personalizada usando ccws/examples/Dockerfile como exemplo.

A imagem pode ser usada da seguinte maneira:

• docker pull asherikov/ccws
• mkdir tmp_ws # Fontes, construir, instalar, cache irá aqui
• docker run --rm -ti -v ./tmp_ws:/ccws/workspace asherikov/ccws bash
• make wsinit REPOS="https://github.com/asherikov/qpmad.git"
• ...

Estendendo CCWS

A funcionalidade CCWS pode ser estendida de várias maneiras:

• Ao adicionar novos perfis de construção, por exemplo, make bp_new BUILD_PROFILE=vendor_static_checks BASE_BUILD_PROFILE=static_checks , todos os perfis que começam com o prefixo vendor são ignorados pelo git;
• adicionando perfis de execução;
• As metas make podem ser adicionadas criando um arquivo ccws/profiles/build/vendor/<filename>.mk ;
• O sufixo comum da cadeia de ferramentas cmake pode ser adicionado ao ccws/profiles/build/vendor/toolchain_suffix.cmake .

Questões conhecidas

• Falha de segmentação durante a compilação cruzada ou a geração de pacotes do Debian Indside Docker Containers (ambos requerem proot ): presumivelmente devido ao recurso seccomp Linux, que pode ser desativado com --security-opt seccomp:unconfined do docker. Desativar seccomp para proot com PROOT_NO_SECCOMP=1 parece ser desnecessário.

• Programas compilados com sinalizadores ( addr_undef_sanitizers ou thread_sanitizer perfis de construção) Saída 2: AddressSanitizer:DEADLYSIGNAL ou FATAL: ThreadSanitizer: unexpected memory mapping quando executado: o motivo da retenção da memória SANC (Layout Randomization) em Linux. O problema pode ser aliviado definindo sudo sysctl vm.mmap_rnd_bits=28 .

• Alguns dos pacotes principais do ROS2 não podem ser construídos com CCWS devido ao uso indevido de cmake, por exemplo, consulte o AMENT/Google_benchmark_Vendor#17.

• proot Segfault enquanto construía no ARM64 no Ubuntu 22, por exemplo, enquanto construía pacotes Debian. A versão mais recente do proot deve ser usada, consulte Proot-ME/Proot#312.

Software relacionado

• https://github.com/ros-industrial/industrial_ci-scripts de CI específicos do ROS, design não interativo, "One-Shot", sem desinfetante, emulou compilação cruzada.
• https://github.com/ros-tooling/cross_compile/-emulou a compilação cruzada para ROS e ROS2.
• https://github.com/hesselm/rpicross_notes - Compilação cruzada para Raspberry Pi feita de uma maneira diferente.
• https://github.com/ros-tooling/action-ros-ci-ação github que cobre parte da funcionalidade CCWS .
• https://github.com/ros-infrastructure/ros_buildfarm, http://wiki.ros.org/buildfarm-O núcleo da infraestrutura de embalagem do ROS. Complicado, especializado no manuseio de pacotes individuais, em vez de espaços de trabalho, não adequados para reimplementações rápidas de campo.
• https://github.com/colcon/colcon-blendle fornece funcionalidade semelhante a 'superpackages', permitindo empacotar espaço para instalar um único arquivo. Naturalmente, ele não fornece todos os recursos do pacote, como dependências, scripts de instalação, etc. Além disso, não depende do ambiente semelhante a chroot para garantir caminhos corretos.

PENDÊNCIA

• Fuzzing https://github.com/rosin-project/ros2_fuzz, https://github.com/ssslab-gatech/robofuzz, https://github.com/flplusplus/afluzzl, https://github.com/flplusplus/afluzzl, https://github.com/flplusplus/afluzz, hittps:
• Investigue a geração de pacotes de depuração e desenvolvimento.
• Construa reproduzível https://reproducible-builds.org/.
• Substitua ccache por https://github.com/mbitsnbites/buildcache.
• Integrar https://github.com/oclint/oclint
• https://github.com/ejfitzgerald/clang-tidy-cache ou https://github.com/mbitsnbites/buildcache pode ser usado para cache clang-tidy .
• https://github.com/mrtazz/checkmake pode ser útil para o Linering Makefile.
• O Cache Cmake verifica com https://github.com/cristianadam/cmake-checks-cache, https://github.com/polysquare/cmake-forward-cache também pode ser útil.
• Shell Formatter https://github.com/mvdan/sh.
• https://github.com/myint/cppclean pode ser útil para detecção desnecessária de cabeçalho, mas parece obsoleta.
• https://github.com/include-what-you-use/include-what-you-use
• Análise de tempo de construção com Clang https://github.com/aras-p/clangbuildanalyzer e/ou https://github.com/jrmadsen/compile time-perf.
• Potencial substituição para scan_build https://github.com/ericson/codechecker com verificações e cache extras.
• https://github.com/SSCPAC/Statick não será usado, mas alguns de seus linters podem ser integrados.
• Código -fonte Check https://github.com/myint/scspell.
• https://github.com/jordansissel/fpm-gerador de pacotes binários genéricos, substituição potencial para dpkg-deb .
• https://github.com/git-afsantos/haros-Análise estática Ros-Aware, pode ter problemas com os ambientes de construção não catkin_make .
• https://github.com/tencent/tscancode - Ferramenta de análise estática C ++.
• https://github.com/dlu/roscompile/tree/main/roscompile - liner para pacotes Catkin.
• Use https://libguestfs.org/ ou https://github.com/alperakccan/fuse-ext2 em vez de dispositivos de loop, para evitar o uso do sudo. No entanto, existem alguns problemas no Ubuntu, bug 759725, consulte https://libguestfs.org/guestfs-faq.1.html. guestfs é muito lenta para ser prática.
• O suporte à compilação distribuída com https://github.com/distcc/distcc pode ser útil.
• Adicione o perfil do desinfetante da memória como uma alternativa ao valgrind , gcc não o suporta atualmente.
• Adicione perfil de cobertura de código.
• Perfil de execução com https://github.com/yuGr/libdebugme para iniciar automaticamente o depurador em um sinal.
• https://github.com/yugr/valgrind-preload como uma alternativa ao perfil de execução valgrind -um exagero em geral.
• Controle Visibilidade do símbolo e verifique com https://github.com/yugr/shlibvisibilitychecker.
• Adicione CodeQL Profile (https://github.com/github/codeql).