 Bonjour, tout le monde, bienvenue à l'infrastructure de Jenkins public week-limiting. Nous sommes le 13 septembre 2022. Aujourd'hui, nous avons moi-même Tamiya du Portal, Bruno Verharten, Stéphane Merle, Marc Waite et Hervé Le Meurre. Je n'ai pas oublié. Vous pouvez trouver la note collaborative sur la chatte de Zoom. Cela sera publiée dans la communauté. D'abord, je suis désolé. Nous sommes tardes sur la publication de la recording des meetings précédentes, mais pas sur les vidéos. Marc, vous pouvez confirmer que les prévues que vous avez menées sont encore sur le compte Zoom. Je peux les rétribuer et les publier sur YouTube. Ils sont sur le compte Zoom. Je n'ai pas délévé. Je n'ai pas publié. C'est trop léger de les publier. Ce n'est pas un problème. Je les prends. Je vous remercie d'avoir regardé les prévues que vous avez menées. Je suis désolé, parce que le premier jour de mes holidays, c'est comme si Marc était aussi off. Je n'ai pas oublié d'avoir regardé les prévues. J'ai promis que ce ne va pas se passer. La prochaine fois, je vais partager le compte Zoom avec vous, les gens. Merci d'avoir regardé. Let's get started with announcements. So as usual the weekly. So someone has passed on me. So the 2.368 version of Jenkins has been successfully released. At least the war file, the document and packages are currently being built or already published. And I assume the rest of the checklist for the release has to be run, but almost there. Is that correct? OK. That's correct. And the Docker image exists now as well. So I just confirmed it's visible also. So Stefan, you know what will be the next step after that meeting for you? Yes, I know. Stefan is our new designated volunteer to update the Docker image of Jenkins. No, I did volunteer. But you are doing a great job. So thanks for that. That's quite the removal of Montala burden for me. So many thanks. Don't hesitate to ask the other and to rotate the role because it can be quite annoying. So don't worry. Many thanks. Do you have other announcements? OK. Let's review the upcoming calendar. So next weekly. Next Tuesday. If I'm correct. Next week. A usual. Next. Yes. I don't remember. When is it planned? When we have 28 days from September 7. So October 4 or something. I can look it up. Damien. OK. Cool. So that mean after the DevOps fold. So no worries right now. Correct. Your mission in front team is we should check that after that meeting we all add if it's not the case, either the public Jenkins calendar with that information or a new event on our team calendar. For the next LTS. That's a core responsibility. Next security release. I'm sure they have one. Published yet. Any dates. So yes. There might be one in the coming months. As usual. As soon as it's public, we can talk about that. Next major event. So. I haven't seen a lot of 21 of September for the security release that is planned and we talked about that already. So it's public. OK. So 21 of September. So Friday next week. Am I correct? Friday. No, I think you're looking. I think you're looking on October 21, September is a Wednesday. You ought to be very frightened. Be. Perfect. So let's mean it's not a weekly day. So that mean don't merge anything that they, as usual. A next major evidence et nouvel spoiled into week were. Part of the team here will be travelling so we shifts. les summits des contributaires. Je ne me souviens pas du temps spécial, mais j'ai proposé que nous annoncons les summits de l'infra-weekly meeting, parce qu'avec toutes les choses qui arriveront à l'absorption, je me sentais malade pour laisser Stéphane rentrer le meeting. C'est très bien. C'est en fait le jour de la summite des contributaires. C'est donc, c'est, c'est, c'est incroyable pour les quatre ou les cinq de nous dans ce meeting maintenant pour attendre. C'est vrai, c'est exactement le collège des summits des contributaires. C'est donc, oui, c'est possible pour moi. Oui, et je n'ai pas l'accès au CDS pour la registration, pour la recording. Si c'est le seul problème, nous pouvons le partager avec vous. Non, non, c'est ça. Vous pouvez l'utiliser. Je veux dire, vous avez demandé pour moi. 40 minutes. Oui. Il y a deux semaines, les summits de l'infra-weekly meeting s'est annoncé. Je ne me souviens pas du calendarié exact. 27, c'est vrai? Correct. Donc, je vais prendre soin de retirer l'invité. Il faut retirer l'invitation du calendarié. Ok. Pas de grands événements, comme je le sais. Donc la prochaine semaine doit être la relance de sécurité, le week-end, partie de la team du U.S. Et le week-end, nous devrions avoir un relance de l'invité LTS. C'est assez l'agenda. Ok. Let's proceed with the tasks. Merci beaucoup Nervé pour le système automatique qui nous permet d'extracter ces tasks. C'est une façon utile et utilisable. Je prends les tasks dans l'ordre des notes de meeting. Ça devrait être la même, mais oui, avec Github, je ne suis pas sûr qu'on a tous les mêmes vies. Et donc, je prends les notes sur le côté de la main. Nous avons eu un « build feeling » avec des images Packer, qui s'apprenait seulement sur les machines virtuales Linux, toutes les CPUs, toutes les cloud, pas sur Docker, pas sur Windows. Et sur ces machines virtuales, il y avait des packages Python installés. Et quand c'est installé sur les machines virtuales, le contenu de la package n'est pas exactement le même que quand vous installez sur un contenu. C'est parce que Python est un default user pour Peepworks. Et parfois, il ne s'agit pas de downloader toutes les dépendances transitive. Nous avons mis deux dépendances transitive dans le processus. Donc maintenant, ces dépendances transitive pour la Azure CLI ont été ajoutées explicitement. Donc, nous sommes sûrs que c'est installé sur toutes les plateformes, et ça ne n'est pas encore possible. Je n'ai pas entrapé la liste exhaustive de la dépendance transitive de la Azure CLI. Je l'ai parlé, je les ai listées, et j'ai décidé de justifier l'issue, parce que ajouter plus de 200 dépendances transitive était un peu trop grand. J'ai espéré Peep à faire ça pour moi, donc oui. Nous n'avons pas utilisé le package de distribution, parce que ce n'est pas publié par Microsoft pour IRM Machines. Et nous avons un IRM Machines en fonction des différents, où nous avons besoin de command line AZ. Donc nous continuons à utiliser Python Installation. N'importe quelle question. La prochaine, approfondez le domaine de JenkinsIo sur la organisation GitHub. C'était un fixe pour JenkinsSinfra et JenkinsIo. Merci à la surveillance pour prendre soin de cette vidéo, parce que nous avons mis la certaine organisation GitHub, qui est une organisation séparée. Donc ils ont fait toute la levier avec la team SEQ. Et maintenant, ils ont eu ce bon badge sur leur organisation. Donc, beaucoup de merci. C'était bien. J'ai oublié quelque chose sur ce sujet? Rémouvez JC, pour Python GroovyLip plugin. Je pense que la team, ou... est-ce que la team ou la URV ont remis ou même Marc? Merci Marc. Donc, JC n'est pas allé, mais c'était un plugin formel qui a été remis à autre place, sur un autre sujet. Donc, ça a fait du sens. C'était une administration de Jira. Et je ne suis pas sûr que tout le monde est sur la team Infra. En fait, un administrator de Jira. Je ne pense pas que ça soit ça. Oui, donc ça peut être... Je ne sais pas si c'est ça. Mais la raison est que ça vous donne accès à la sécurité de JenkinsIo. Donc, vous avez accès à des données sensitives. Ce n'est pas que nous ne vous entrons pas, mais moins que les gens aient accès à ça, c'est mieux parce que, quand vous avez accès, vous pouvez extracter toute la liste de vulnérabilité de Jenkins. Ce qui est qu'on préfère garder le modèle, c'est juste qu'on a besoin d'une personne de l'infra-héber pour accès à la Wolffling. Archive Custom Distribution Service. Donc, oui, ça a été fait. C'était un service former qui a été retiré depuis l'infra quelques mois, et je suppose que c'était la repositorie. Merci, Team, d'avoir regardé cette liste. J'ai ajouté à préparer un projet pour ajouter la commande à IAC, mais aussi à acheter la repositorie et à changer la description. Oh, bien. Est-ce qu'il y a un souci pour extracter ou est-ce que je devrais mettre ça dans le progrès de travail? Il n'y a pas d'issue pour ça. Il n'y a pas besoin d'une personne. Juste pour savoir où j'ai écrit ça. Encombre travail à Hervé. Merci beaucoup. Pour avoir un IAC, mais... Archive commande. Merci beaucoup pour ça. Le bâtiment du week-end ne se résume pas. Merci à tous ceux qui ont été intéressés. L'issue était si par accident quelqu'un de la team, en particulier d'Amiens du Portal, a été réveillé par des requêtes sur le contrôleur de rédéployement CIE. Et c'est réveillé. Le rédéployement n'a pas été resté. Il y avait plusieurs soucis sur le bâtiment parce que si le contrôleur s'est resté correctement, il devait continuer à marcher avec le bâtiment de travail sur les agents. Mais au début, la plupart des soucis étaient planisés sur un bâtiment parrain qui n'était pas encore requiert d'agents. Donc, on a retiré l'allocation de ce bâtiment pour la rédéployement. Et il a travaillé aujourd'hui sans n'importe quoi. Il a prouvé que ce bâtiment n'était pas requiert. Le but de ce bâtiment parrain est de traiter le rédéployement sub-bâtiment et ensuite traiter le bâtiment. Alors, on a ajouté un système de retrait que JC a travaillé sur que si il y a un problème avec le contrôleur de l'agent dans le bâtiment, il a automatiquement retraité. Donc, il a dit, OK, il a failé et il a retraité une deuxième fois. Et donc, on peut utiliser l'instance spot pour l'instant. Si l'agent est abriplé, alors il retraitera. Jenkins a la connaissance de la raison de l'accès. Nous n'avons pas, et c'est vraiment important pour moi de donner ces détails. Merci à JC, il a pointé que ce système de retrait doit seulement être élevé sur un bâtiment qui est important. Ce qui veut dire qu'on peut faire le même pipeline 2, 3, 4, à peu près une fois, on va avoir les mêmes résultats. Et élever un bâtiment n'est pas important. Parce qu'on ne peut pas override un bâtiment au moins sur la repositive de Maven. On ne devrait pas et ça a été bloqué sur nos systèmes. Donc, si on fait le bâtiment intérieur qu'on fait avec Jenkins, faire le test, créer un nouveau bâtiment et puis déployer un bâtiment sur la repositive, si on fait le deuxième bâtiment, ça signifie qu'on va créer un nouveau bâtiment. Donc, ce n'est pas important. Donc, vous ne voulez pas un retrait automatique en cas de défaut sur un bâtiment. Donc, le dernier bâtiment qu'on doit faire maintenant est que, peut-être, nous pouvons passer sur certaines casées où, durant ce bâtiment, qu'on fait avec Jenkins et des tests. Parfois, le contrôleur pourrait encore réinstaller si la Maven continue d'améliorer le pull request tout le temps. Et il devrait continuer de marcher parce que c'est ce que le pipeline est expecté de faire en cas normal. Mais si on voit des problèmes sur ce bâtiment, donc je me demande Marc, parce que vous êtes l'auteur de ce bâtiment, mais c'est pour tout le monde. Si vous voyez, again, non résumabilité, donc pas un retrait, mais continuant le bâtiment après le contrôleur restart, dans ce cas-là, nous devons avoir un vrai bâtiment et J.C. demande pour plus de détails si nous pouvons reproduire ce bâtiment ou si vous avez vu de nouvelles occurrences. Merci, je vais garder l'oeil. Je vais regarder. Nous pouvons artificiellement essayer. Depuis que nous pouvons rétrégir une weekly release quand nous voulons. Non, je ne veux pas, spécialement avec la sécurité, relise la prochaine semaine, sinon je vais avoir des gens visant moi, physiquement. Et je pense que la relance de la sécurité la prochaine semaine est seulement des plugins, donc vous ne... Mais les bâtiments de la week-end sont plus que fréquent. Oui. Qu'est-ce qu'il y a sur ce sujet? Ok. Le prochain sujet qu'il y a était l'archive extra-executable de la guerre, donc une repositorie qui n'a pas été utilisée plus. C'est été archived. Donc merci, Team, encore pour faire ça. Et l'arrivée, d'ailleurs, si il y a des botes à l'arrivée. Un problème, un outage de la clé de la clé de la clé de la clé de la clé de la clé de l'arrivée. C'est ce sujet qui a été dédié deux semaines auparavant, le dernier jour quand je marchais. Il y a été un déployement de l'AWS autoscalaire. Il a été fixé avant mes holidays, mais j'ai oublié de mettre tous les fixés. Et nous avons réglé les composants et fixé les problèmes. Il y avait un bug dans le charte de l'album. Donc nous devions attendre pour la nouvelle version de la fixation du charte de l'album. Ce genre de choses se sont passé à un moment. Donc nous avons perdu deux bâtiments, deux bâtiments de plugins qui ont commencé manualement. Et ce était un outage de 15 minutes sur ci.genkins.io. Donc le sujet a été fermé avec des détails sur le post-book. Il n'y a pas de plus d'action. Un upgrade ci pour le dernier LTS. Nous avons eu le release de l'LTS. Nous avons dû l'utiliser. Donc merci beaucoup à tous les Stéphanes pour préparer et poursuivre les images de l'album parce que j'avais un state de clé avec seulement les changements qui était relative à l'LTS. C'était facile. Donc dans moins de deux heures, tout était déployé et l'album s'est déployé pour tous les GDK11. Et le dernier, le task complet a été déléter un compte pour être déléter dans ci.genkins.io. Donc merci à la surveille. Je pense que vous êtes les uns qui ont pris care de ça. Donc un souvenir pour prouver l'identité quand quelqu'un a eu une question de déléter un compte. Donc quelque chose relative à l'account dans l'ELDAP. D'être capable de commenter un GERA issue est un moyen de prouver que la personne est capable d'accéder à l'account. Parce que si vous demandez de vous envoyer un email, ce n'est pas bon enough pour prouver qu'ils sont les personnes qui sont prétendues. C'est le contexte d'un compte sur l'account.genkins.io pour les gens qui ont besoin de prouver l'adaptation de GITAM et de l'adaptation de l'opposité. C'est un autre processus. Oui, c'est aussi si ce n'est pas un utiliseur qui n'a pas d'adaptation de l'adaptation de l'opposité d'adaptation de l'adaptation de l'adaptation de l'adaptation avant de déléter l'invité. Et je me demande est-ce qu'il y a un endroit où nous devons mettre ces techniques de déléter parce que je n'aime connaître ces techniques. La technique que l'on a utilisé est vraiment utile avec les газes de économitch famous de l' passado et le bleu de travail de la machine. Si l'on intéresse l'adaptation de gilets pour ce que ce soit ce tout objet et nous avons envoyé unbuch contre celle de GITAM pour trouver une way out deあーже, issue instead. I like that well and and I use a similar challenge on github side to prove that they own a github account asking them please fork the get client plugin repository into your account and that's when I see that the fork is visible I know that they did it. So, so those kinds of challenges I think are a good, a good thing for us to describe and I have never put that fork thing in the in the runbook either so I think maybe we want action items to say update the challenge, the challenge technique so that we know for various scenarios hey if they have their password still have them update and make a comment on a jury issue and that's proof they have it. Nice one so that mean we have to update the existing runbook for that part. Who's volunteering for that. Thanks. Thanks a lot. No more question. Okay I'm proceeding for the work in progress subjects. Latest link for some plugins on archives Jenkins I.O. are outdated. So it's a second topic we already had an issue with the latest on the get Jenkins I.O. mirror system. And now we also have that on archives Jenkins I.O. Avant diagnose yet. Both are different systems. One is as links generated by the updates on the process, which is the case of this one. The other has links that are unreferenced by the Azure CLI command tools pushing to another bucket storage. So these are two different things. We haven't worked on that yet. Just commented and acknowledged to the user because they ask if it was the right place to ask. And if they did something wrong, they didn't. That's an issue on our side. Publish acceptance test harness docker image and release. So now the image is built and pushed as the latest image. The next challenge that underline the big trouble with the CD process of the Jenkins plugins is that Jenkins on our on our instance we have a policy that say don't build a tag, which is older than three days. The goal is that if you accidentally scan a repository that rediscover all the tags since the beginning, you don't want Jenkins to start rebuilding, not only because it consume resource for nothing, but also publishing at the risk of overriding existing docker images in that case. So that's why we put that the problem we have is that the tags created when the CD process use for plugins, it's a GitHub release object. And it's generated by release drafter as a draft. So it's not visible publicly that draft is created. But once you merge your pull request after release, it start creating the new release notes, and it creates a temporary tag. That tag as a unique identifier, then the day you publish the release, it will create a tag associated to the release pointing to the moment in time where you want to release. The kind of git tag created by the GitHub release, which are two systems, is known as lightweight, which means the tag is only a label pointing to a sha. That's all. It does not have a timestamp. The timestamp is the timestamp of the commits. Which means the tag was seen with more than three days old, even if Tim just created it a few minutes before. So Jenkins was not picking it up. And that will be the same with Travys, CircleCI, GitLab, even GitHub Actions. It's just that by default, the tags created by a GitHub release are lightweight. So the solution, because we already met that problem with the Jenkins and Docker images that are not using CD, but still same pattern, release, drafter and everything, we create a special kind of tag name annotated. So it's a tag with a sign body associated to the tag where you can put changelog, message, like with a commit. And when you create an annotated tag, the timestamp becomes the time when the tag with the annotation was created and pushed. For us, it was easy. We did that five months ago. We add the flag-a when creating the tag. So instead of git tag, git tag-a, name of the tag, you push it, and that's all. Here, it's trickier because we had to open a contribution to the CD process. And now, I'm in the process of testing it on the Jenkins plugin infra test to see if it works as expected. Right now, my contribution is not working, but we need that. So I will continue working on that this week if I can make it. And of week, if I haven't find a viable solution, then I will follow JC tip, adding on that specific repository to solve the acceptance test harness problem. We will add a specific GitHub action triggered when a release is published that will take care of annotating the created tag manually. That will be the worst hackish way. But I think if we're able to do that on a specific GitHub action, that's worth doing it on the current action. So, Damien, just to be sure, you've got a way to convert a non-annotated tag to an annotated tag and Git allows that. If you add the flag-dash-force, yes. That's cool. Okay, right. So it's actually a tag replacement that's happening. And so the repository must allow replacement of tags in order for that to work. Absolutely. The thing is that if you can create a release, you can override a tag. There is no blocking. It's not like overriding code. It's different. But there are two downsides. I don't know the behavior if you have a release pointing to the tag that you override. I'm not sure how is the link working. Is the release unpublished or banned or just updated to use the new tag? I don't know. And if you override a tag that was already annotated, you lose the previous annotation. And in the annotation, you have the GPG key signator. So that might create some security issues. So that one was pretty tricky. The good thing is that now Afra CI is able to build and publish images on the Jenkins CI organization. So we can provide that service to more projects on the community, not only the Jenkins Infra itself. The idea here, it's a kind of CD. They can still have CI build and test with the same methods, same tooling, the constraint publicly. And we only do the deployments. So that mean we could ideally start pushing the official agent images, for instance, from Infra CI. I don't say we should. I just say we are technically capable for some projects. Next one. Thanks a lot there for hosting plugins scoring application. So that's a new GSOC project led by Adrien Le Charpentier. With one or two GSOC attendees. I don't remember how much. So we will have to host that as infrastructure in a way that they make them as autonomous as possible for the scope of the GSOC. And then we will see how to productize this one. That means providing them CI, which we already did a few weeks ago. And now it was the CD part, if I understand correctly. We are more in the CI part. I did a parameter to be able to understand artifact. Like in the case, the dot char build. And so I've modified or build the current publish image function. So we can stash that fact generatable before calling this function. So this one is good. I have to add some tests in the pull request on the pipeline library. So it's clean. And then I think Adrien is working on the end chart. Oh cool. Use this doc image. I proposed him to make it, but he wanted to take a look. So. Good. With the end chart, we will have to add the database somewhere. And then we will be able to post this on public K8S, just on Azure. So if you need information about database, don't remember that Stefan worked a few months ago on manage PostgreSQL database on Azure, and Terraform. So you should be able to take the work from him. So don't hesitate to ask him to pair. That will be interesting to work together on that, if there need be. And she stuck student needed a neural to put in the form. So I've put a redirection place on plugin.dash.genkins.io. It's redirected to, for now, the GitHub page of the plugin scoring repository. So it's displaying as you written for now. We don't hear you, Damian. Sorry, I was muted. I might have muted. Sorry. So thanks a lot. That's a lot of works. Many thanks. Don't hesitate to help continue helping Adrien, like you do. That's really important that they are, they don't wait too much on us, and they are as autonomous as possible. I think once the initial installation will be done, that will be easy for them to continue to deliver them. Any more question? So next one reintroducing artifact caching proxy for CI.genkins.io. Just because I forgot to talk about that on the announcement. So we had a meeting with GFrog. We will need to start a discussion that should mainly take place during the contributor submit in two weeks about the future and how we use GFrog Artifactory System. We have a constraint is that we need to decrease our bandwidth usage on the system. The order of magnitude is five to six times less bandwidth should be consumed. We consume a lot. We have learned a lot. Daniel started knowledge sharing with me about legacy, even if Mark already has some. So the goal is continue working on that area. There are multiple solutions. That old solution will involve an import on our area. First point, I have been granted by Daniel yesterday access admin access to the repository. So I should not require that access. It's a separate account. But I will publish a run book with the rules. The main rule is don't delete anything. And the second rule is don't zap the cache. Absolutely. I will open an issue that Daniel shared with me. We have a virtual mirror. The same database currently building for that topic. And that virtual mirror does not have corresponding upstream since month or years, which means if we zap the cache, we lose artifacts that are used. So we will have a task to download all the artifacts of that specific virtual mirror and store them again on G frog as a stored system. Yeah. Knowledge sharing. Can I let you then take the next step to explain the status and the problem you are solving or facing on the mirror for that repository inside our infrastructure. So why that's scops it. So I'm still bouncing around some error permission error. I fixed the health probe I needed for the container in cubanets. And I'm working on the digital ocean proxy providers. I have to I am I had the last week. And I'm now deploying an external load balancer. So I can refer to it. If you address more easily. So this is in progress. I think as soon as as soon as I fixed the health and permission error, I will be able to good see as your proxy in tests. Or start. And then we will be able to add the other provider. As soon as they are ready. Nice job. That wasn't an easy one. Honestly, because it's really an edge case for a cubanet as their term of pattern. Digital ocean incoming. So next step test it. Is that a good summary. Yes. We have the Jenkins test plugin for basic testing. And I like to know I will ask what is a plugin with most dependency. So a big one to build. Search. Big. Cool. Is the git begin more having a lot of maven dependencies. It has some maven dependencies. Is is a lot. How would I assess a lot Damian sorry. I have no idea. Looking at the log of my van. Time for one coffee or two coffee. Oh, oh, you're saying download. Oh, okay. Any plugin downloads most of the internet. Let's build, right? That's. So it's, it's coffee counting the. The way to know. Yes. Sorry. Maven dependencies. Forward brewing machine for coffee. Hmm. That will be a nice October fest. Thanks a lot. Oh. On-off. C'est un truc de messe de plus important. So we have to continue the effort there. That's a. A way to communicate. So toulkies frog that we are working actively on reducing the bandouille is conception. We'll get back to. Publicly, with more information once we will start the topic. We might need to run some experiment on the infrastructure. pour nos agents. C'est-à-dire qu'il y a une réquestion pour le LDAP pour chaque mail et le download. Parce qu'à la première étape, on ne sait pas si... il n'a pas l'air d'avoir un LDAP authentication caching pour une session sur GFrog. Mais il y a peut-être quelques, parce que c'est la seconde chose. On va avoir une migration de GFrog. Ils m'ont dit qu'ils doivent encore communiquer et qu'ils vont migrer d'un point de vue principal qu'ils utilisent pour leur nouvelle plateforme. Donc nous devrions pouvoir revenir sur leur système. Cela signifie qu'il y a presque 1 outage sur repo.genkinci.org. Ils vont communiquer avec nous la date et la temps. Nous devrions avoir des statuettes à ce moment. La bonne chose, c'est qu'ils vont avoir un accès qui sera intéressant. En temps de storage, on a déjà... On a déjà eu des informations sur l'admin. Mais surtout sur storage, c'est plus dur que de bandwidth. Pour les métriques, si vous avez une question sur GFrog ou MiroRing. Les métriques data-dog sont pour un accès cluster. C'est rare et je n'en comprends pas, mais il n'y a pas de métriques pour un accès cluster public. Je n'en comprends pas pourquoi, parce que Temp Private fonctionne en Azure. C'est la même version. EKS et DOKS sont parfaitement fine. Nous avons toutes les métriques et tout fonctionne bien. Nous avons pris l'opportunité de faire l'installation de la data-dog sur un accès cluster en mode de high availability recommandé par l'enjeu. Mais il y a encore des métriques que je n'en comprends pas. Il n'y a pas d'horreur message sur les agents cluster. Nous devons agir un peu plus. Nous avons des métriques portionnelles, mais pas toutes. Pourquoi nous avons détecté ça, parce que le travail que Hervé fait, il faut vérifier des métriques sur l'artifactoire. Donc sur DOKS, vous avez beaucoup de métriques. Mais grâce au travail de Olivier, nous avons aussi des métriques complémentaires et des métriques de Hervé. Si vous ouvrez votre VPN et allez au Grafana Genkins IO, vous devez atteindre nos instants privés qui circulent sur le public public. Et il y a un dashboard avec beaucoup de métriques. Surtout, c'est vraiment utile pour traiter les processus de mémoire. Mais aussi le usage de CPU. Donc c'est le travail en progrès, parce que nous devons vérifier un peu plus. Merci Hervé pour l'entraînement. Nous avons accès aux accounts de Twitter. Hervé, vous avez fait un proposé pour peut-être, revocer les outils utilisés par DLVR et ajouter une nouvelle automation et implementation. Donc le but de cet account c'est de créer des tweets qui viennent de la publication de l'RSS des plugins et des projets sur Genkins. Je dois quand même répondre à l'application de DLVR pour que le ticket soit ouvert. Peut-être qu'ils ne peuvent pas changer l'email d'une autre email, mais avec le même domaine Coshike. J'ai envoyé un email mais je n'ai pas eu des réponses et je n'ai pas voulu remercier le jeu. Maintenant que nous savons que l'email associé à l'account est Coshike, nous pouvons encore lui remercier l'account comme nous l'avons fait pour le Twitter. C'est ce que j'ai demandé. Oui, mais c'est Coshike sur cette pile d'emails. Je vais prendre la prochaine escalation et si ça ne marche pas je vais l'escalier à Marc, Daniel ou les gens plus close à Coshike. Et on le verra à DevOps, en fait. On va être à l'album avec Coshike et c'est une grande opportunité si on n'est pas résolu par Vin. On va dire, hey, on va le faire ensemble. Je suis sûr qu'il y a un computer. En tant que je sais, il le fait très souvent. Oui. Bien, merci pour le souvenir. J'ai oublié que c'était attendu. Ok, donc LV et A will be our mission during the DevOps world. So I propose that we put that one on all the for the in it weeks. Looks good for you. Yes. C.I. Jenkins, you're collecting data dogmetrics for the ephemeral virtual machine agents. So Stefan, almost there. I will say exactly the same thing than last week. Almost there. I think that for that it's just going to production but I need to make sure with you how I will do that. This one, I did Azure. I did EC2 Amazon and it's now working since yesterday or even this morning. Next phase and cool. Great job on that one because then we will be able to publish a dashboard to our developers so they can start analyzing the resource usage of the builds on the virtual machine will be especially useful for the acceptance test on some core builds. Many thanks for that work. Next one still you, Stefan. So we have the high level topic is providing Java 17 windows agents. We have the all in one container. Oh, that's why it's for me because it shouldn't be for me because there's windows in there. Container. Yes. So it's for Linux, but that's the first step because it's easier to manage because we have mostly Linux knowledge. So the goal is to have the same Docker image. Whatever kind of container agent you run as soon as it's Linux and that image is built by Packer, which means you have the same tools and the same path as the virtual machine templates. So I think that this one is close for Resolve 2 as I'm right now trying it on the plugin, the test plugin, infratest plugin and I saw that it's crashed on the 17 but I'm not quite sure of why, but I'm in a good direction. Cool. Which means once we have this one we only have to communicate to the developer and we will try your rollouts. Oh, I will have to... For now it's only on Digital Ocean so I will have to put that on the other Kubernetes 2 and we will have to discuss how we merge that to the production and talk into developers first. First we send an email with the timeline, but that's my proposal. We send an email when we are sure that it works on bus with your testing. We send an email saying here is the issue here is the timeline and the day of the timeline you have prepared a pull request that remove your testing templates and change the existing one they keep the same name and labels but you change the rest of the setup and we try. If it doesn't work we revert it back to the old images and then we keep watching for the builds and the feedbacks but the most important part is to let developers know that it's not because of them but because of us and they can let us know it's not working so we can quickly revert and unblock them if needed. I thought that we will keep the old agent as a backup with another name No, because there will be no way as you discovered on the pipeline library code there is no way for the developer to say I want to use the fallback and it's better to have only simplified configuration so we have less things to test at the given time and if it doesn't work we roll back and start again with a test Looks good? Yes. So almost there. Next step still on that topic I've almost successfully built a windows container with the same provisioning script as the virtual machine I'm in the process of what is missing on the windows server on the windows container that all the cloud machines have on the template for windows server I had issues with the pod ssh some packages but almost there I have two tools on the 24 tools that we installed two that are missing so almost there which mean once windows container are okay then we can start adding the windows 17 agent with the all in one pattern windows container I'm failing only the provisioning but right now on my request infracia is already able to spawn a windows machine and build container which mean the EV lifting has already been done that should help us a lot No more question? A word on separated pipeline for update CLI LV started to split into pipelines for Kubernetes management as the first POC for that concept the idea is to have separated pipeline and separating jobs in infracia that take care of running update CLI diff and apply so then we will have less complex pipeline because split into github workflow Right now we are using a static definition with job DSL of multi branch pipeline for this one to validate that checks and everything works in the usual workflow simple requests and it's blocked by a missing feature on our end chart that define the jobs for Jenkins controller and kube we want to use a github organization and it's not implemented yet it's on a matter of writing the template the goal is we would have a github organization scanning the search all Jenkins in fra for pipeline named Jenkins underscore update CLI and it would automatically run them as an update CLI process standard, no more configuration it's only automatic scanning that's the initial idea that might be wrong we might need some specific pipeline or credential that we won't share or specific tuning that will make us having to define specific multi branch but right now we don't see a lot for the only the scope of update CLI so then the convention will be add that pipeline that will work we can improve and iterate we could use a file token per repository there are multiple solutions but we are there the goal is to simplify our pipeline so they are faster and we won't wait for update CLI we parallelize as much as possible did I miss something Hervé nope ok chart POC on Kubernetes management thanks for that work Hervé publish pipeline step dog generator on backend extension indexer that will be for next week the goal is to stop having CLI Jenkins IU publishing files that are used to build Jenkins IU website not only it's unsafe but also it's slowing down security processes so the goal is to have a job on infra-CI which is mainly a report job so the result of this builds on a bucket which is publicly available because the goal is that having that data but that data will be generated on infra-CI so we can stop CLI Jenkins IU and rebuild the website Jenkins IU still successfully even with CLI Jenkins IU down haven't worked on that yet anyone interested can start working on that it's build on jobs otherwise I will use it I will take it as fallback haven't started working on mirror brain cleanup that involve maybe breaking all the publication of all plugins so I'm still careful on that one I need it to go back to work and be having some brain time it's blocking the migration to Oracle for the updates Jenkins IU so next step for me I've taken care of incoming work by Hervé and I think that's already a lot of work from the world team there Hervé et Stéphane thanks for taking care of this huge issue that you are both working on that might not looks like you are working on a lot of issues at the same time but these issues are huge, really huge thanks for that if anyone is wants to add a topic something new something that I forgot that's the time now I don't have something else to add so I will close the meeting publish this meeting and the previous recording and create a new milestone Hervé I will need your help for the releases and that's all for me today thanks everyone thanks everyone