Forum Linux.embarqué Quel environnement pour compiler du Yocto en CI ?

Posté par  (Mastodon) . Licence CC By‑SA.
Étiquettes :
3
31
août
2020

Bonjour,

Yocto c'est bien, c'est très bien. Mais pour pas être emmerdé, il faut une distribution assez précise parmi celles qui sont supportées officiellement, par exemple Ubuntu 18.04 LTS.

Je voudrais monter une CI (Sous Jenkins vraisemblablement) qui entre autre compilera l'image Yocto. Pour être indépendant de la CI elle-même, je me doute que un système dédié à la compilation Yocto est plus simple à maintenir. De plus ça peut servir en développement système d'avoir sa propre image de compilation.

Mais j'hésite entre partir sur du Docker ou une virtualisation (KVM par exemple). Ou autre chose ?

Je ne connais bien aucune des 2, donc j'apprendrai (avec plaisir) ce qu'il faut. Je n'ai pas vraiment de critères de performances (bon, si l'une des deux multiplie le temps de compil' par 10 évidemment…), plutôt des critères de stabilité et de facilité de maintenance (je suis dans une PME, on n'a pas un temps complet pour maintenir la CI).

Merci pour vos retours !

  • # Expérience avec Docker

    Posté par  . Évalué à 2.

    Salut,

    Pour l'avoir mis en place sous Gitlab avec Docker, c'est pas ouf en termes de performance.

    Pour gagner en temps on avait mis en place le cache en NFS (plusieurs builds parallèles pouvait taper dedans en même temps du coup). A posteriori, il aurait mieux valu une VM que des dockers. Ca aurait été plus simple à configurer pour l'accès NFS. L'avantage des dockers c'était la facilité d'intégration avec Gitlab.

    Pour utiliser Jenkins désormais, les dockers sont plutôt bien gérés aussi.

    Bref je suis pas sûr d'avoir trouvé la solution idéale (Gitlab + Docker) mais ça fonctionne encore, c'est pas très compliqué à mettre en place et les collègues arrivent toujours à le faire tourner (moi j'ai quitté le navire).

    Si tu essayes Jenkins + VM je veux bien un retour : je réfléchis à mettre ça en place dans mon nouveau taf pour Petalinux

  • # Ça dépend

    Posté par  (site web personnel) . Évalué à 6.

    Yocto c'est bien, c'est très bien. Mais pour pas être emmerdé, il faut une distribution assez précise parmi celles qui sont supportées officiellement, par exemple Ubuntu 18.04 LTS.

    Pour info tu peux t'affranchir de cette problématique même si ce n'est pas conseillé. Je compile toujours mon Yocto de travail sur la dernière version de Fedora mais ça implique souvent de récupérer ou faire quelques correctifs.

    Mais j'hésite entre partir sur du Docker ou une virtualisation (KVM par exemple). Ou autre chose ?

    Les deux options sont raisonnablement bonnes. Cela dépend de la taille et des habitudes de ton équipe aussi. Mais aussi de ce que tu veux faire avec la CI : ressources du serveur, nombre de compilations à faire par jour, etc.

    Pour économiser des ressources et récupérer pas mal d'artefacts, j'ai utilisé Docker mais en le configurant pour partager certaines choses notamment les fichiers des logiciels à compiler. Car re-télécharger 20 000 fois GCC 9.1.2 ce n'est pas spécialement utile, autant avoir un endroit où tout est stocké en guise de cache pour gagner du temps et de la bande passante.

    Donc il faut que tu sois assez à l'aise avec Docker et que ton équipe sache s'en servir pour en tirer profit. La VM à ce niveau là c'est sans doute plus simple.

    • [^] # Re: Ça dépend

      Posté par  . Évalué à 1.

      Je conseille également de prendre une VM, d'autant plus que le projet Yocto propose une procédure avec une image QEMU toute faite pour la compilation. C'est évoqué en détail dans ce guide pour les utilisateurs qui ne sont pas familiers avec cet outil de virtualisation.

      En solution intermédiaire entre KVM/QEMU et Docker, c'est possible de prendre des containers LXC à la place où on peut utiliser une partition dédiée à la compilation sans trop de souci. Cependant, je ne trouve pas de tuto spécifique concernant Yocto pour ces containers. Cela peut s'envisager comme une solution plus "légère" (avec moins de fonctionnalité, forcément…) pour la maintenance comparé à la VM si besoin.

      • [^] # Re: Ça dépend

        Posté par  (site web personnel) . Évalué à 5.

        Je conseille également de prendre une VM, d'autant plus que le projet Yocto propose une procédure avec une image QEMU toute faite pour la compilation. C'est évoqué en détail dans ce guide pour les utilisateurs qui ne sont pas familiers avec cet outil de virtualisation.

        Les documents dont tu parles utilisent QEMU pour tester les images produites avec Yocto, pas pour les produire.

        Cela aide pour l'aspect tests et vérifications mais pas pour automatiser la CI.

        • [^] # Re: Ça dépend

          Posté par  . Évalué à 1.

          C'est vrai. J'ai lu assez rapidement et je n'ai pas réalisé que l'utilisation de QEMU intervient après la compilation.

          Je me sers de ce wiki pour mettre en place une VM complète. Concernant l'utilisation de la CI avec QEMU, je ne sais pas si une solution sur étagère le prend en charge en revanche.

  • # GitLab CI + VM

    Posté par  . Évalué à 1. Dernière modification le 02 septembre 2020 à 12:37.

    Pour de l'embarqué avec buildroot, j'utilise Gitlab + VM (Debian). Dans la terminologie de GitLab, c'est un gitlab-runner de type shell.

    • C'est facile à mettre en place
    • C'est facile à maintenir
    • Il est facile de changer de CI puisque qu'elle se contente de faire un git clone récursif suivi d'un make all

    Pour moi, le point le plus important était de pouvoir recompiler mon projet à l'identique même dans 20 ans sans dépendre d'aucun serveur externe. Aussi j'ai archivé toutes les dépendances dans GitLab et je me sert de git submobule pour les référencer dans mon projet.

    Par exemple, j'ai archivé une copie du dépôt Git de Buildroot ainsi que le répertoire .buildroot-dl qui sert de cache pour les téléchargements.

    J'ai aussi archivé tous les DVDs de la distribution Debian que j'utilise pour la compilation ainsi que tous les outils tiers qui ne sont par fournis par Debian (par exemple Intel Quartus Lite).

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.