this repo has no description
Continue rapport
+39
-2
+10
bib.yaml
+10
bib.yaml
···
912
912
date: '2025-10-28'
913
913
value: https://github.com/Gepetto/gz-unitree/pkgs/container/gz-unitree
914
914
915
+
cicd:
916
+
type: article
917
+
title: What is CI/CD? Continuous integration and continuous delivery explained
918
+
author: Sacolick, Isaac
919
+
date: 2021-06-01
920
+
publisher: InfoWorld
921
+
url:
922
+
date: '2025-10-29'
923
+
value: https://www.infoworld.com/article/2269266/what-is-cicd-continuous-integration-and-continuous-delivery-explained.html
924
+
rapport/cicd-commits.png
rapport/cicd-commits.png
This is a binary file and will not be displayed.
+28
-1
rapport/gz-unitree.typ
+28
-1
rapport/gz-unitree.typ
···
907
907
908
908
== Mise en CI/CD
909
909
910
+
911
+
On appelle CI/CD (pour _Continuous Integration / Continuous Delivery_) la pratique consistant à intégrer fréquemment des petits changements à un dépôt de code source commun, en lançant des tests régulièrement (partie "CI") et éventuellement déployer la base de code fréquemment (partie "CD") @cicd.
912
+
910
913
Une fois l'enregistrement vidéo rendu automatisable, si l'on veut mettre en place le lancement automatique à chaque commit du dépôt git de la politique (i.e. chaque changement de la politique), il faut crééer une description de _workflow_ (dans notre cas, un workflow _Github Actions_).
911
914
912
-
Un workflow est un ensemble de commandes à exécuter dans un environnement virtualisé (qu'il s'agisse d'une machine virtuelle ou d'un simple container), ainsi que des évènements et conditions décrivant quand lancer l'éxécution (par exemple, "à chaque commit sur la branche `main`").
915
+
Un workflow est un ensemble de commandes à exécuter dans un environnement virtualisé (qu'il s'agisse d'une machine virtuelle ou d'un simple container), ainsi que des évènements et conditions décrivant quand lancer l'éxécution (par exemple, "à chaque commit sur la branche `main`"). C'est un des outils permettant de mettre en place la CI/CD.
913
916
914
917
=== Une image de base avec Docker
915
918
···
980
983
981
984
Les environnements de CI/CD s'apparentent plus à des serveurs qu'à des ordinateurs complets: en particulier, il n'y a pas d'interface graphique et donc pas de serveur d'affichage (_display server_).
982
985
986
+
Mais Gazebo nécéssite un display server pour enregistrer une vidéo.
987
+
988
+
Il convient donc de simuler un serveur d'affichage. Dans notre cas, l'environnement de CI/CD étant sous Linux, on simule un serveur X11 avec _XVFB_ @xvfb.
989
+
990
+
==== Un environnement de développement contraignant
991
+
992
+
#grid(
993
+
columns: 2,
994
+
gutter: 2em,
995
+
[
996
+
Développer et débugger une définition de workflow peut s'avérer complexe et particulièrement chronophage: n'ayant pas d'accès interactif au serveur éxécutant celui-ci, il faut envoyer ses changements au dépôt git, attendre que le workflow s'éxécute entièrement, et regardé si quelque chose s'est mal passé.
997
+
998
+
Par exemple, si jamais des fichiers sont manquants, ou ne sont pas au chemin attendu, il faut modifier le workflow pour y rajouter des instruction listant le contenu d'un répertoire (en utilisant `ls` ou `tree`, par exemple), lancer le workflow à nouveau et regarder les logs.
999
+
1000
+
Ceci rend le développement assez fastidieux, surtout quand le workflow peut durer plusieurs minutes.
1001
+
],
1002
+
figure(caption: [Commits liés au développement du workflow],
1003
+
box(
1004
+
clip: true,
1005
+
inset: (right: -20cm, bottom: -5cm),
1006
+
image("./cicd-commits.png")
1007
+
)
1008
+
)
1009
+
)