Un prototype publié dans la communauté ROS 2 veut rendre les décisions de backport moins artisanales. Présenté le 18 août sur Open Robotics Discourse, il combine deux GitHub Actions pour comparer l’ABI binaire d’un paquet C/C++ entre une branche cible et une pull request, puis afficher un verdict directement dans le flux de revue.
Le problème visé est familier aux mainteneurs ROS : un correctif peut déjà exister dans Rolling, mais ne pas avoir été rétroporté vers une distribution supportée comme Humble ou Jazzy. Les utilisateurs découvrent alors le bug en production, enquêtent, puis doivent demander eux-mêmes le backport. L’auteur du prototype propose de déplacer une partie de cette vérification vers la CI.
Deux actions pour séparer l’outil et le contexte ROS
La première brique, libabigail-action, est générique. Elle construit deux versions d’une bibliothèque partagée et lance abidiff, l’outil du projet GNU libabigail, pour repérer les changements d’ABI. Elle n’est pas limitée à ROS et peut intéresser tout projet C ou C++ qui publie des bibliothèques.
La seconde, ros2-abi-action, ajoute le contexte ROS 2. Pour chaque pull request, elle construit le paquet dans le conteneur de la distribution concernée, compare l’ABI binaire, applique la politique REP-0009 et publie un commentaire persistant. Le résultat peut signaler une compatibilité ABI, une rupture, un label et un check de CI exploitable par les mainteneurs.
Pourquoi cela compte pour les robots
Dans une pile robotique, les changements de bas niveau ne sont pas abstraits. Une rupture de compatibilité dans une bibliothèque utilisée par la navigation, le contrôle ou les drivers peut bloquer une flotte entière, surtout lorsque les équipes industrielles figent leurs versions pendant longtemps. Automatiser une partie du contrôle ABI ne garantit pas qu’un backport est fonctionnel, mais cela réduit l’incertitude technique au moment de décider.
Le prototype reste prudent sur ses limites. Un label « ABI compatible » n’impose pas de rétroportage : un changement de comportement peut surprendre un robot même si la signature binaire reste stable. Les templates, fonctions inline et effets de bord doivent aussi être relus par des humains. L’intérêt est plutôt de fournir un signal standardisé, visible au même endroit que les tests et la revue de code.
Notre analyse
Le sujet est moins visible qu’un nouveau robot, mais il touche directement la fiabilité des logiciels utilisés sur des machines physiques. ROS 2 avance par distributions longues, backports et paquets maintenus par des équipes très différentes. Un workflow partagé d’une dizaine de lignes, s’il est adopté par des dépôts centraux comme rclcpp, rcl ou rmw, pourrait éviter une partie des corrections redécouvertes tardivement.
La prochaine étape sera l’adoption réelle par les dépôts cœur et la mesure du bruit en CI. Trop d’alertes rendraient l’outil pénible ; trop peu de couverture le rendrait décoratif. Mais l’approche va dans le bon sens : traiter la compatibilité comme une donnée de maintenance continue, pas comme une vérification manuelle de dernière minute.
