Fermes de construction ROS

Les fermes de construction ROS sont une infrastructure importante pour soutenir l’écosystème ROS, fourni et maintenu par Open Robotics. Ils fournissent la construction de packages source et binaires, l’intégration continue, les tests et l’analyse pour les packages ROS 1 et ROS 2. Il existe deux instances hébergées pour les packages open source :

  1. https://build.ros.org/ pour les packages ROS 1

  2. https://build.ros2.org/ pour les packages ROS 2

Si vous envisagez d’utiliser l’une des infrastructures fournies, veuillez envisager de vous inscrire au forum de discussion de build farm afin de recevoir des notifications, par exemple, à propos de tout changements.

Emplois et déploiement

Les fermes de construction ROS effectuent plusieurs tâches différentes. Pour chaque type d’emploi, vous trouverez une description détaillée de ce qu’ils font et de leur fonctionnement :

  • release jobs génère des packages binaires, par exemple, des packages debian

  • devel jobs construit et teste des packages ROS dans un référentiel unique sur la base d’une interrogation

  • pull_request jobs créez et testez des packages ROS dans un référentiel unique déclenché par des webhooks

  • Les tâches CI créent et testent des packages ROS sur plusieurs référentiels avec la possibilité d’utiliser des artefacts d’autres tâches CI pour accélérer la construction

  • doc jobs génère la documentation de l’API des packages et extrait les informations des manifestes

  • divers travaux effectuent des tâches de maintenance et génèrent des données d’information pour visualiser l’état de la ferme de construction et ses artefacts générés

Création et déploiement

Les travaux ci-dessus sont créés et déployés lorsque les packages sont bloomed, c’est-à-dire publiés pour ROS 1 ou ROS 2. Une fois que le blooming est réussi et qu’un package est incorporé dans l’une des distributions ROS (via une demande d’extraction à rosdistro), les travaux correspondants seront générés . Les noms des tâches encodent leur type et leur objectif : 1

  • travaux de libération :

    • {distro}src_{platf}__{package}__{platform}__source construit les packages source des versions

    • {distro}bin _{platform}__{package}__{platform}__ binary construit les packages binaires des versions

    Par exemple, le travail d’empaquetage binaire de rclcpp sur ROS 2 Humble (fonctionnant sur Ubuntu Jammy amd64) est nommé Hbin_uJ64__rclcpp__ubuntu_focal_amd64__binary.

  • métiers de développement :

    • {distro}dev__{package}__{platform} effectue une construction CI pour la branche de publication

  • travaux pull_request

    • {distro}pr__{package}__{platform} effectue une construction CI pour une demande d’extraction

    Par exemple, le travail PR pour rclcpp sur ROS 2 Humble (fonctionnant sur Ubuntu Jammy amd64) est nommé Hpr__rclcpp__ubuntu_jammy_amd64.

Exécution

L’exécution des travaux dépend du type de travail :

  • devel jobs sera déclenché chaque fois qu’un commit est effectué sur la branche respective en fonction d’une fréquence configurée.

  • pull_request jobs seront déclenchés par des webhooks à partir de la demande d’extraction respective du dépôt en amont 2

  • release jobs sera déclenché une fois chaque fois qu’une nouvelle version de package est publiée, c’est-à-dire qu’une nouvelle demande d’extraction rosdistro a été acceptée pour ce package. Les travaux source sont déclenchés par un changement de version dans le fichier de distribution rosdistro, les travaux binaires sont déclenchés par leur homologue source.

Questions fréquemment posées (FAQ) et dépannage

  1. ** Je reçois des e-mails Jenkins suite à l’échec de travaux de construction de ferme. Que fais-je?**

    Allez à l’emploi qui a soulevé le problème. Vous trouverez le lien en haut de l’e-mail de Jenkins. Une fois que vous avez suivi le lien vers la tâche de build, cliquez sur Console Output sur la gauche, puis cliquez sur Full Log. Cela vous donnera la sortie complète de la console de la version défaillante. Essayez de trouver l’erreur la plus importante car c’est généralement la plus importante et les autres erreurs peuvent être des suivis.

    Le bas de l’e-mail peut indiquer 'apt-src build [...]' failed. Cela est généralement dû à une erreur lors de la construction du paquet. Cela indique généralement des dépendances manquantes, voir 2.

  2. Il semble qu’il me manque une dépendance, comment puis-je savoir laquelle ?

    Vous avez essentiellement deux options, a. est plus facile mais peut prendre plusieurs itérations, b. est plus élaboré et vous donne un aperçu complet ainsi qu’un débogage local.

    1. Inspectez la tâche de publication qui a soulevé le problème (voir 1.) et localisez le problème de dépendance cmake. Pour ce faire, accédez à la section cmake, par exemple, accédez à la section build binarydeb via le menu de gauche dans le cas d’une tâche de construction ubuntu/debian. L”Erreur CMake indiquera généralement une dépendance requise par la configuration cmake mais manquante dans le package manifest. Une fois que vous avez corrigé la dépendance dans le manifeste, effectuez une nouvelle version de votre package et attendez les commentaires des fermes de construction ou…

    2. Pour obtenir un aperçu complet et un débogage local plus rapide, vous pouvez exécuter les tâches de publication localement. Cela permet d’itérer le manifeste localement jusqu’à ce que toutes les dépendances soient corrigées.

  3. Pourquoi les tâches de publication échouent-elles lorsque les tâches de développement/mes actions github/mes builds locaux réussissent ?

    Il y a plusieurs raisons potentielles à cela. Tout d’abord, publiez les travaux construits sur une installation ROS minimale pour vérifier si toutes les dépendances sont correctement déclarées dans le package manifest. Les tâches de développement/actions github/constructions locales peuvent être effectuées dans un environnement où les dépendances sont déjà installées, donc ne remarquent pas les problèmes de dépendance. Deuxièmement, ils peuvent créer différentes versions du code source. Alors que les tâches de développement/actions github/constructions locales construisent généralement la dernière version à partir du référentiel upstream 2, les release jobs construisent le code source de la dernière version, c’est-à-dire le code source dans les branches upstream respectives du référentiel release 3.

Lectures complémentaires

Les liens suivants fournissent plus de détails et d’informations sur les batteries de build :

1

{distro} est la première lettre de la distribution ROS, {platform} ({platf}) nomme la plate-forme pour laquelle le paquet est construit (et son code court), et `` {package}`` est le nom du package ROS en cours de construction.

2(1,2)

Le référentiel upstream est le référentiel contenant le code source d’origine du package ROS 1 / ROS 2 respectif.

3

Le référentiel release est le référentiel que l’infrastructure ROS 2 utilise pour publier les packages, voir https://github.com/ros2-gbp/.