 Bienvenue pour cette petite updates sur le state d'Azul-based CI infrastructure pour Fedora. Alors, première, nous allons introduire nous-mêmes. Je suis Mathieu-Huain et je vais vous présenter ce talk avec Fabien Boucher. Notre travail d'aujourd'hui est de maintenir des deployements d'Azul à Red Hat. Selon les opérations, nous aussi et les personnes qui ont commencé avec Zool. Et aussi, nous contribuons à aller au projet d'Azul. Dans ce talk, nous allons vous donner une updates sur le state d'Azul-CA. La plateforme avait un couple d'improvisations, depuis la dernière fois que nous avons parlé de cela durant DefConf.CZ, l'année 2020. Mais première, peut-être que nous devons vous donner un petit souvenir de ce que l'Azul-CA est. Donc, c'est un effort que nous avons commencé à l'étudier le 19 juin. Le but était d'offrir un système de CI alternative à Fedora, basé sur Zool. Il a été développé et opéré par la team de production de Red Hat OpenStack, c'est-à-dire Fabien et ma team. Fedora Zool-CI est obtenu dans un déploiement largeur qui est hosté par notre team, et ce déploiement est appelé le software factory project. C'est le public déploiement qui hoste CI pour les autres projets, entre autres. Nous avons donné CI infrastructure pour projets hostés sur piper.io et src.fedoraproject.org, et nous also supportons des projets hostés sur GARIT instances et Github. C'est-à-dire que CI peut être élevé pour les projets Fedora. Finalement, le projet donne des emplois et la déploiement de la validation sur les progrès pour les packages Fedora, c'est-à-dire ces Giths sur src.fedoraproject.org. Nous avons commencé à l'étudier, parce que nous savons que la CI pour Fedora présente beaucoup d'advantages. La première, Zool est un système de code-gating qui déclare les tests de dépendance et la validation de spéculation, pour assurer que les changements relatives sont testés et intégrés ensemble. Donc, bien sûr, l'approche de dépendance est particulièrement bien souhaitée pour ces Giths, parce que les dépendances entre les packages sont très communes. La deuxième, la validation de spéculation des aspects de Zool accueillent les problèmes d'intégration avant qu'ils soient élevé. Et depuis que la configuration de la CI est aussi code, parce que c'est tendu dans la repositorie, cela signifie que les changements de la CI peuvent être testés et validés sans le besoin d'infrastructure de staging. Zool est sa propre infrastructure de staging. La deuxième, Zool est aussi un service réelable. Donc, il a été en développement pendant 9 ans, et les changements sont encore en train d'être faits. Et nous devons voir la prochaine majorité de versions être élevées en 2021. Aussi, Zool a aussi été adoptée par des projets où la CI est critique, comme OpenStack, l'industrie automobile et les autres. Et cela a été apprécié chaque fois pour sa compréhension. Et enfin, et c'est quelque chose que nous avons proposé au projet grâce aux développements que nous avons faits. Le Fedora Zool CI est plutôt un play plug-and-play. Nous avons juste trainé un projet sur le Fedora Zool CI, et ça a été rendu straightforward. Et les défauts de la CI et les tests et les environnements couvrent de la plupart des outils. C'est aussi possible pour vous donner vos ressources. Si la communauté Fedora veut s'utiliser avec HUP, les ressources dédiées peuvent être élevées par les AWS, par OpenStack, par Metall ou d'autres outils. Et enfin, et c'est quelque chose que nous avons acheté très important, le Fedora Zool CI donne la validation de la CI sur les progrès. Et de cette façon, cela fait que le progrès de la workflow est variable et donne plus d'opportunités pour contribuer à l'accompagnement avec un workflow familial pour mettre en place des patches. Donc, ensuite, nous allons parler de ce qui s'est passé depuis l'année dernière. Et je vais l'aider à Fabien pour cela. Merci Mathieu. Donc, précédemment, en utilisant la Fedora Zool CI, il a besoin d'un changement dans un setting projet, à moins, ajouter le webbook URL pointé à Zool, qui a été utilisé. Pour retirer cette constrain, nous avons développé un service qui écoute le boost de Fedora messager et le message forward qui est connecté au pull request pour Zool as web pilote. Donc, grâce à ces improvements, il y a un step less pour les maintenants de l'accompagnement de Zool CI pour ajouter la Fedora Zool. Plus recentement, Zool a été installé dans une instance de GitLab. Le driver de GitLab a été utilisé dans Zool en septembre 2020 et est éso-functionnel comparé à d'autres drivers Zool. Donc, cela signifie que les jobs existants en infrastructures offerts par Fedora Zool CI pour transmettre simplement à GitLab si Zool moves à GitLab. Maintenant, nous allons parler de notre stratégie pour couvrir les compositions de Fedora Zool CI. Fedora consiste de 30 000 compositions de Fedora Zool CI et nous ne pouvons pas, comme aujourd'hui, offerter les compositions de Fedora Zool CI pour toutes les compositions. Il y a aussi la majorité d'un packageur qui n'utilise pas le pull request pour contribuer. Donc, ajouter le pull request d'une base CI workflow et cette base Git est érelevante. Donc, nous avons créé un outil pour rechercher les compositions de cette base Git qui ont reçu un pull request recentement et l'a implementé par l'utilisation de Fedora Data Draper pour gérer mes trucs. Et aussi, le outil est capable de notifier le maintenancement en mai, quand Fedora Zool CI a été attaché à la base Git. Merci à cet outil, nous pouvons régulièrement s'attacher à la base Git de la base Git de la base Git. Nous regardons l'inspect RPM, donc, à chaque update pull request, Fedora Zool CI a créé un travail de l'inspect RPM qui performe comme l'inspect RPM entre les propositions de l'inspect RPM et les prévues publiques de l'inspect RPM sur CoG. Cependant, l'application de la production de la base Git est difficile pour le maintenancement et ensuite, nous pensons que ce travail a une utilisation de la utilisation. Pour faire le travail plus relevant, nous avons créé l'inspect RPM web app qui prétire la base Git créée par l'inspect RPM. L'inspect RPM est générique et est installée sur softwarefactoryproject.io. Et aussi, il est déjà ennuyé pour Fedora Zool CI et il peut être utilisé par les Fedora Zool CI pour les gestes de la base Git et les réputés de l'inspect RPM. Il y a un screenshot de l'application web. Comme vous pouvez le voir, il a pris un URL de l'inspect RPM dans la forme web qui est facile de réutiliser par les autres Fedora CI. Et aussi, vous pouvez voir les messages de l'inspect RPM à la base Git et nous pensons que c'est utile parce que certains packages peuvent produire des messages de l'inspect RPM. Et aussi, nous avons recentement décidé qu'on a besoin d'un jobselecteur pour assurer que l'inspect RPM fonctionne correctement. D'ailleurs, cette base Git n'a pas une définition STI test. Donc pour elles, à moins, nous avons besoin d'un package installé. Donc, nous avons implémenté un jobselecteur test qui est capable de détecter la définition STI test pour un test RPM ou un jobselecteur RPM. Pour vous rappeler, le jobselecteur RPM installe un jobselecteur. Simplement, essayez d'installer le build RPM. Et le jobselecteur RPM installe le build RPM et puis, l'inspect STI test est défini dans la base Git. En particulier, le code G scratch build. Donc, notre structure n'a pas donné une machine virtuale et pour la fonctionnalité de test. D'ailleurs, le workflow de jobselecteur de la base Git a fait un build scratch avec le code G X8664 d'arche override. Mais, c'est important d'y aller dans le cas de build failure de nos architectures supportées par Fedora. Donc, nous avons offert un jobselecteur RPM pour chaque architecteur supporté par Fedora. Le jobselecteur conditionnel a été checké pour les arches et pour les extraits de jobselecteurs pour le jobselecteur d'arches. Maintenant, nous allons donner une statistique de Fedora Zul CI. Donc, nous avons currently offert un CI pour 387 de la Git. Le CI a offert plus que 10 000 jobs que nous avons porté dans 2000 build sets. Et le CI expérimente seulement 15 nodes de failure. C'est-à-dire que 99 % de travail n'est exécuté sans l'infrastructure. Ici, c'est la liste du top 5 projet par un nombre de bâtiments. Vous pouvez noter que c'est principalement les packages Python, mais pour une bonne raison, parce que nous avons principalement travaillé avec les packages Python pour improving Fedora's UCI. Maintenant, nous allons donner des instructions sur comment, comme packages, vous pouvez interroger avec Fedora's UCI. Ici aussi, c'est la liste du projet, où vous trouverez la même instruction. Alors, nous allons présenter un packageur. Hey Fabien, je suis le transient error et j'aimerais remercier les jobs de la UCI. Est-ce que je peux le faire ? Oui, c'est sûr que oui. Juste commenter la preuve pour les requêtes avec Recheck. Hey Fabien, j'aimerais utiliser la UCI pour tester un change lié à une version de bump sur une des dépendances dans mon package. Mais la même bump n'a pas été mélangée. Est-ce que je peux le faire ? Oui. Dans le cas où la package dépendante est proposée par la preuve pour les requêtes. Ensuite, vous pouvez ajouter Zool pour inclure la preuve pour les requêtes, donc les RPMs, dans l'environnement de test test. Donc, pour cela, ajoutez une zone dépendante dans l'initiel commun de la preuve pour les requêtes. Comme vous pouvez le voir, vous pouvez également lire plusieurs requêtes dépendantes. Mais ce n'est pas seulement supporté pour la dépendance de runtime, spécialement pour le test RPMs sur le test RPMs install test-to-job. Hey Fabien, je suis malade. Je ne veux pas que je le fasse constamment sur mes patchs pour que je fasse un build de FedPKG dès que les armes sont émergées. Est-ce que ça pourrait être automatisé ? Oui. Ce n'est pas une partie de la preuve pour les requêtes, mais vous pouvez laisser Zool publier sur le code G sur votre behalf. Pour cela, vous pouvez s'occuper d'une preuve pour les requêtes en ajoutant le template public sur le job FedPKG. Hey Fabien, ma preuve de test-to-job s'est faite et je ne peux pas reproduire le problème localement. Est-ce qu'il y a une façon de faire quelque chose de bug sur l'environnement de l'exécution ? Oui. Avec Zool, c'est possible de mettre un test-to-job sur tout le monde pour que la preuve de test-to-job soit faite pour votre changement. Vous pouvez ensuite s'assurer qu'il n'y ait pas d'automatique. Il faut être reçu par IRC sur le secteur software ou la chaîne Fedora CI sur 3 nodes. Fabien, je suis convaincu. Comment ai-je mon projet sur Fedora Zool CI ? C'est génial. Pour attacher un disque sur Fedora Zool CI, j'ai simplement ouvert une preuve de test-to-job sur le projet Fedora Config Repository. Et ensuite, la preuve d'exécution de Fedora Zool CI sera traite par la preuve de test-to-job sur la preuve de test-to-job. Maintenant, nous allons parler de nos listes pour le futur. Nous aimerions continuer à improving le projet Fedora Zool CI ainsi que de la utilisation plus grande. Le prochain improvement que nous aimerons c'est de supporter la zone de dépense à la preuve de test-to-job. Nous avons pu construire sur Fedora QG, mais il n'est pas possible qu'il y ait d'autres repositions pour être ajoutées dans le code Gmock route. La solution pour mitiger cela pourrait être d'utiliser un scopeur où un Mock route peut être créé par un API et où d'autres repositions pour être ajoutées par l'attribution. Une autre solution serait d'utiliser un local Mock route dans le test-to-job. Mais, nous ne sommes pas sûrs d'implaner efficacement. Nous avons besoin de votre input. La troisième c'est similaire à la test STI qu'on aimerait aussi ajouter un support pour les tests T80. Il y a d'autres efforts qui ont commencé récemment, mais ce n'est pas fini. Nous voulons avoir le même support entre TMP et le test-to-job de Fedora QG. Finalement, on aimerait que les gens puissent s'involver en gardant ou créant des efforts pour Fedora QG. Je pense que nous sommes prêts pour cette présentation. Il y a des ressources qui sont nécessaires. Et si vous avez des questions ou des commentaires, feel free to ask.