 Hello everyone, welcome to the weekly Jenkins Infrastructure Meeting. Today we are the 8th of November 2022. Around the table we get myself, Demian Du Portal, Hervé Le Meurre et Stéphane Merle. We don't have Mark, Tim or Bruno. Let's get started. As a reminder, last meeting was two weeks ago. As far as I can remember, 25 octobre. Let's get started with announcement. The new weekly is almost terminated as usual. The Docker container should be available in 10 minutes. I've triggered manually the build on trusted CI. The base release is OK. Container image now available. Rest of checklist item later today. Looks good. Do you have other announcements on your site? I don't either. Upcoming calendar. Next week I'm not totally sure because there is a security release next week. And that will be Thursday as far as I can tell. So I don't know the scope of the security release. So I can't tell if it's on the core or only plugins. If it's only plugins then we should have the weekly as usual. Otherwise, if it's core, we will have a new weekly. So a weekly will be scheduled Tuesday for sure. Next till TS is planned end of November, as far as I can tell. Let me just double check on my agenda. I think it's around the 30th of November. The two 375.1. Yes. Last day of the month. Next major event. February for them. The CI CD room has been accepted. So if you have any idea to submit a talk, please do it. So the CI CD room will host a lot of bunch of talks around CI CD as the main thematics. There is also Golang Devroom. So expect some Jenkins contributor present there. So if you want to submit a subject, don't hesitate. You can submit a two person. But don't wait too long if you have an idea. That is usually 3, 4 February 2023 in Brussels. Nothing more for you. Let's get started. So that was a huge two weeks iteration. First pattern if my, if GitHub want to load on my machine. We had a lot of closed and open issue about people starting to ask for a password reset. I'm not sure which kind of events triggered that. Hello GitHub. It's only me that has issues with GitHub. Is it my ISP? Let me check. You don't have some issues with me? No. It's perfect. Okay. So we had a lot of issues with sign up, plug in people with issues. No, GitHub is not getting here neither. It's very slow. Okay. Let me open in advance all the issues then. So we already have on the backlog an help desk template for a country recovery issue. The idea will be to add a special template when people open issues to help them because that's always the same pattern. People ask for a credential or a reset. We don't know which credential, which person. We don't know where did, what did they try. So at least having a template would be easier to close the issues if they don't provide the right information. So thanks everyone involved on sending some never answer. So it's closed as no action. Some answer with issues that allowed us to fix element. So that was just for this tiny minor issues. Missing data doc metrics for the pod public gates AKS cluster. So now we have metrics so that issues was closed because we saw some metrics appear last month. But in fact, we were missing a lot of metrics. There were error message due to misconfiguration. So it wasn't no, it wasn't misconfiguration. It was a change on AKS that dates since five, six months. And the data doc agent is run on each work node and is contacting the local cubelette, which is the Kubernetes agent in charge of spawning pods and doing stuff. The connection to the cubelette is using TLS. So we had, we have to configure data doc to mount the certificate authority to allow the data client to contact in HTTP plus TLS without any issue. However, in the case of AKS, the only solution with data doc is to disable TLS verification. There is, which mean it's encrypted, but there is no verification of the certification chain. Because the certificate presented by the cubelette doesn't have a son, a field son. I don't know why it's recurred. I haven't deep down, but that's let's say a recommendation by both Microsoft and data doc that say disable TLS for data doc. So changing that and now metrics started to populate again. It's still encrypting the data inside the TLS using cubelettes, another cubelette certificate. So that mean if you have a random pod, it cannot pass for the cubelette because there is a sign sign signing system. So no worries on that area. So that one allowed us to enable the engine integration that was working on. So thanks folks, because that one was quite tricky. Remove PPC64 mention on CIG and Kinsayo. Thanks Bruno. Thanks Stefan for doing all that work. Now it's easier and we don't have outdated things. Artifact download failed on agent using repo cache. Thanks a lot RV for taking care of the ACP artifact caching proxy service, especially with the early users. So thanks for fixing the issues. Access to npm name space finally has been recovered. Giving us everything required for putting web components and whatever npm library under a lage name. Thanks RV for that work and giving as well. Alex blondes did not have administration right on Gira. So I took care of archiving the modules. It's quite easy. If you are Gira admin, you have to go on the administration. You select the Jenkins projects and there is a list of components and there is a button archived for each. That's really easy. Windows ACI 11 agent broken because Git wasn't in the path. So it was fixed less than one day after the issue was read. However, we had to add integration test to the image builder to ensure that that problem doesn't happen. So we might still see issues. We have to grow the integration test harness for these images, but now it has been fixed. There has been request permission. So I think either Tim or Alex took care of that. More component archive. Twitter Jenkins release is now working again. Thanks RV for that work. That was a long understanding issue. So can you confirm it's a new system? Yeah, it's a new system that we installed on the clusters. Right. I'm using access to Twitter repository. It's a go application. It's running on hot public ATS cluster. And it's fetching the SS feed every five minutes and publish a new tweet every new week. Nice. Nice job, really useful. And at least now the whole team can operate it instead of being locked to a special cloud account. I'll probably do a look around Twitter together, GitHub action, which I'll also publishing tweets as code. I've discussed this with Mark and it's interesting. Absolutely. Cool. That that also has been a long running discussion. As far as at least in four or five years, so. That will be cool. Next issue. CIG and Kinsayo does not have enough. So permission on the missing repositories. So some repositories weren't allowed on the exhaustive list for the GitHub app. If I'm correct. So CIG and Kinsayo using the GitHub app automatically generated and changing token wasn't allowed to fetch. It's not the only repository. That mean, I mean, that happen. Sometimes it's weird and making us waste time. I don't know if we have an easy way. That would mean having GitHub as code. We have an issue open for that, but it's not that easy. I have to look into it. On one of my to do list. Hosting team onboarding. So thanks a lot everybody for tracking that one. A big issue. Upgrade to Kubernetes 1.23. So congratulations folks. You were able to do it before end of October. So we weren't locked out on digital ocean. And it will be dropped. 1.22 is planned to be dropped in Amazon end of November. So nice timing. It was quite an easy one, especially in AWS. So great, great work on that one. And we can already start planning the next one. But I particularly appreciate the fact that both of you took a lot of notes and feedback so we can benefit from our mistakes or learning each time. Really, really useful. That absolutely change the pace of the upgrades. We never had such a pace. We are almost up to date to the latest available Kubernetes on our clouds. I'm quite proud of the team for that achievement honesty. Not receiving reset account password email. Another issues like the login issue. Crowd in localization for locable resource. I assume it was treated by someone else. Okay. So no infrastructure task update center returning 404. So that one. Thanks Daniel. He answered the person was using an unofficial feature of the date center, which was during sometimes it was generating dynamic jason for the date center index. Daniel gave them gave them the new official way with the documentation link. So nothing to do on our side and we were able to close. And one last password issue. Did I miss something that we finished that is not on that list? Nope. Okay, let's go to the work in progress then. Okay, so. CI Jenkins IO stories is not handling pull requests. So multiple action there first. The root cause seems to be missing permission on the GitHub app. I was able to discover that because I created a new. A new a new job. And it was failing and by looking at the logs that was the main issue. However, I've moved. I've removed the stories from the infra GitHub organization folder on CI Jenkins IO. And now there is a static multi branch configuration on the folder website. That's a website, not really tied to the infrastructure. It's a multi branch so it can be tuned to have different settings than the rest of the other websites, which wasn't possible with the infrasettings. The less infrasettings we have on that automatic folder, the. The hazier it will be to provide feature to the end users. So. Missing permission. New job location on CI Jenkins IO. And now the work in progress is unifying the two pipelines. Right now we have a Jenkins file built by CI Jenkins IO and the Jenkins file, whatever, built by infrasettings. Thing is that we saw that pattern on the plugin health and some other repositories as well. Having two different pipelines makes not visible anything that happened on the private infrasettings. So infrasettings should be while it should only be used for continuous deployment. So the tentative I'm doing is to have one single pipeline. The CI part will be done on CI Jenkins IO and only the deployment part. The Docker push should be done on Docker infras. In real life, both controllers will do all the steps in parallel at the same time except they will be using the same templates, the same tools, the same steps. So any issue on CI Jenkins IO will be visible on infras. And infras CI should not be triggered with the pull request only during build on the main branch. So less workload on infras CI and more visibility and actionable for the contributor publicly without requiring access to the VPN. If we are successful on that one, we can generalize the pattern to other. The main pain point today and that's why I spent some time on the backer image is that we have a custom container on infras CI and we have our current backer image on CI. So we had to transplant all the missing tools so both pipeline can do the same thing. Adding missing tools. Any question on this one? Okay. Login issue to be done. I mean, we are waiting for I think Mark answered. I don't think we should spend time on that one. The person should answer or we will close it. Forget password, same issue. Windows agent on CI Jenkins IO disconnect prematurely. So sounds like there has been an issue, but it was on the acceptance test mark logged in on the issue that it was testing for the windows label, but that label is not expected to be used. It might have been but now we have windows 2019. We have windows on different areas. We have windows with maven 11 windows is maven and jdk 8. I mean, we have different so that label should be removed, but we need to search for usages and adapt the acceptance test that it map to reality. I mean that one of those nod agent is not working properly. He got the label windows and he got probably tons of other labels. We haven't checked. We haven't checked the reason why it was failing. The acceptance test trying to spawn a windows was failing. I don't know that could be an error in the acceptance test, but good points. That's why I'm proposing to remove the windows label because for sure, there might be a cloud template implementing it. If we remove it, then either we might have some hidden jobs or people doing word stuff since years with the windows label. And then in that case, they will be waiting on bill q blocked. So then we can pull request the repository and change it. But yeah, the acceptance test wasn't testing the reality. That's the thing because Mark wasn't able to see the same behavior in your life use cases. So incident should be closed because there wasn't really an accident, but only once either the acceptance test is fixed or the label windows is removed. No incident but label windows to be removed acceptance test to be updated. Does it make sense for both of you? Yes. Not just missing on agents. So I did a change for the stories using starting to use our custom container web builder. There was same that was used on infrasci. We will have the same issue with the packer image container that I plan to use as soon as possible as well. Thing is that Node.js must be loaded in the environment using SDF on Linux. I don't know why, but after that change using a starting to use SDF, some of the whatever npm command line tool AGV, I think. They try to resolve Node.js from the Shebang user bin on. And it fails. I don't know why so that need more diagnosis because that could be a reason for not installing Node.js using SDF. I have so many issues and a lot of people are doing symbolic things between Node.js and CISPAS. Which defeats the purpose of, do we agree? So that means stop installing Node.js with SDF and using an official Node.js release. The reason of using SDF on the packer image is because it does a lot of things for us. And it allows to have multiple version installed at the same time, which now we need for Ruby. That's the only real requirement. For the rest, whether we use an SDF command, which means we install a SDF, we install a SDF plugin and install the line and set it as global and set the environment variable. Or we do this five, same step, download the correct version of whatever installer on it, add the path of the environment variable and you're done. So there is no complexity difference between both. Sorry, Stéphane. We see you speaking, but we can't hear you. Sorry, forgot to unmute. But we will have only one version if we install manually, if we use a SDF, we can install multiple version and choose the right path to use. The question is, why do we need multiple version? Oh, I don't have any answer on that. I don't. Maybe we have reasons. Maybe because we want to test this version, but right now we don't. So that could be the way to solve that issue. Which is blocking the usage of PackerImage container for Node.js base builds. Also, there are alternatives like NVM. NVM is a, sorry, NVM is a tool that allows to install different Node.js version on the same path and switch from one to the other. Worth asking, gave in a team on that topic. And Alex. But Alex seems more back-end developer than front-end developer. I don't know if you have any advice or points on that. I know you have quite the experience on Node. The question is, do we need the question of Node? If not, we should install it with the official talent. Don't bother more. Okay. I propose we go that way. Install from official installer. First on docker-builder. Then on PackerImage. Does it sounds good for you? Pipeline step-dog generator and back-end extension indexer. So work is done. But need to enable CI for public visibility. So same thing as the unifying, the pipelines that we have for story. We want external contributor when they change the code to have a public available CI. And only the full generation or at least the full upload to report Jenkins.io of the generated report should be in infras CI. Same as stories. Stéphane, vous avez mentionné quelques jours que vous avez été intéressé à apprendre un peu plus sur Jenkins Builds et pipeline. Dans un plus avance de façon, parce que vous le savez maintenant. Mais ceci est un cas de l'âge. Vous êtes intéressé à m'aider à apprendre un peu plus sur un exemple de vie? Bien sûr. Ok, donc je vais prendre le temps avec vous. Donc nous gardons ces problèmes en ligne. Artifact caching proxénable de délivrer des changements de base. Est-ce que vous pouvez nous donner un statut sur celui-ci? Parce que je n'ai pas suivi. Marc, j'ai noté deux clés à l'horreur. La première était le mavent central Time Out. Ce que nous n'avons pas fait beaucoup. Mais la seconde était le problème avec l'artifact caching proxénable sur Azure. Ok. Avec Getaway Time Out Error. En regardant les logs, nous nous indiquons que les erreurs sont seulement sur les providers Azure, non sur les providers digitales. En tant que partition de la série, il y a environ une troisième pour Azure. Donc nous sommes suspectés, c'est le problème de l'IP avec Azure. Ce qui pourrait être la cause. Donc j'ai créé le nouveau privé KVTAS cluster. C'est le problème de l'artifact caching proxénable de délivrer des changements de base. Ça fait le sens. Merci pour ce statut, c'est ok. Je pensais que c'était un issue de priorité. Le privé KVTAS plus publicates fix-ups. Ok. Hello Mark. Ok. Donc ça va être un issue de priorité plus tard. Donc si c'est ok, Hervé, peut-je vous ajouter un commentaire avec ce statut sur l'issue? On peut changer l'issue de l'issue de l'issue de l'insulte de l'infra-nexte. Parce que nous devons résoudre l'issue de la net-work pour résoudre le caching proxénable. Vous pouvez vous répéter? Vous pouvez ajouter un commentaire sur l'issue? Oui. 3, 2, 1, expliquer qu'on doit travailler sur les privés KVTAS et les lier sur les deux issues. Je pense que si je fais le commentaire, je vais vérifier. Peut-être que c'est déjà fait. Si c'est le cas, c'est parfait et il n'y a rien à faire. Mais maintenant, nous ne pourrions pas pouvoir marcher ici parce que c'est bloqué, mais nous devons fixer l'application de l'IP. Pour sûr, maintenant. Nous avons mesuré et laissé avec ça. Merci pour le commentaire. La prochaine question, Nous devons ajouter un point de vue de l'issue pour un point de vue de l'issue. Parce que, par le sud de la pique de cette réquestion, nous devons essayer de nous aider. Au moins, ça serait plus facile de cacher si nous n'avons pas de informations. Je n'ai pas des informations. Ok, alors vous vous gardez en charge de ça. Cool, ça a été une question. Je vais ouvrir un draft pour le commentaire et l'improvement. Cool. On va ouvrir un draft pour des feedbacks. Merci. Si vous ne voulez pas, nous pouvons le faire aussi. Ne vous inquiétez pas. Juste un moment. Le backlog a déjà été construit dans Q&C iGenkins.io. Nous n'avons pas vu plus d'issues sur Q&C iGenkins.io. Même si nous avons restarté tout à l'heure, depuis l'installation. Mais nous n'avons plus de biais. J'ai envoyé un message. Nous utilisons une version de la plug-in, qui n'est pas en ligne avec la dernière version de la plug-in. On va laisser la plug-in maintenir et trouver la solution. La proposition est que nous gardons ça jusqu'à la prochaine meeting. Une semaine plus. Parce que, pour sûr, on va avoir un restart. Et ensuite, nous verrons. J'ai proposé même le 16 novembre, même si le 15 va être la relance de sécurité. Donc, probablement, on va restaurer le contrôleur pour installer un système. Et puis, on va faire un test. On va restaurer le contrôleur pour installer un système. C'est pour ça que l'on s'occupe après. J'ai proposé que nous n'avons pas de travail pour le faire sur cette plug-in. Nous l'avons fait sur la plug-in. Et nous reviendrons la prochaine semaine. C'est bon pour vous? Oui. Je vais le commenter. Réintroduirez le procès d'artifact cashier pour Q&C iGenkins.io. J'assume que vous avez donné un statut juste avant. Oui. Vous avez donné un statut. Oui. Oui. Oui. Oui. Oui. Oui. Oui. Oui. Oui. Oui. Oui. Oui. Oui. Oui. Oui. Oui. Oui. Oui. Oui. Oui. Oui. Oui. Oui. Oui. Oui. Oui. Oui. Je l'ai aussi évoqué des improvements à l'éplan de l'élevé. Tout d'abord, nous pouvons définir un variable global d'environnement qui est disponible. Donc, nous pouvons, par exemple, dédiger l'AWS1 si c'est outre ou c'est stoned. Et j'ai également ajouté une check avec un simple écure, avant de utiliser le provider pour voir si c'est correct. Si non, ça fallait retourner à l'opposé de l'Ontario. Fallait retourner à l'Ontario, si c'est correct. Et j'ai également fixé l'erreur de l'Ontario. C'est parce que je n'ai pas utilisé le correct limiter pour l'ambiance de l'Ontario. C'est un caractère, un caractère pour l'Ontario, mais pas juste pour l'Ontario. Tout va commencer à s'occuper. C'est comme ça qu'il va s'occuper, la prochaine fois, on va dire pour l'Ontario. Merci beaucoup Thierry, c'était assez fort. C'est une féminité. La prochaine fois, c'est la base de Kiklog database. Stéphane, pouvez-vous nous donner une statue de celle-ci ? Oui, j'ai commencé à essayer un drap de la presse de backup. Et bien sûr, il y a beaucoup d'erreurs, donc j'ai besoin d'assurer que la presse de backup est faible, mais je pense que l'usage que j'ai utilisé pour la presse de backup n'a pas assez d'erreurs pour aller dans le backup. Mais c'est nouveau, donc j'ai travaillé sur ça. Ok, ça veut dire que vous avez déjà créé le database, right ? Oui. Ok. La destination nouvelle de ce database est créée dans l'instance database de l'existence que l'on a acheté dans l'Asia. C'est un instant flexible, donc on a de l'availabilité et tout. Nous n'avions pas acheté l'availabilité. Ok. On s'en souviendra. Ok, cool. Merci. Qu'est-ce qu'il y a d'autre sur Kiklog ? Non. C'est un travail en progress, vous êtes expérimenté, et nous espérons qu'on a un premier test d'une certaine température. Pour savoir comment faire le switch, parce que durant cette presse de backup, nous aurons un temps de down. Scale down, Kiklog, 0 replicas, puis migrate le data, puis scale. Nous aurons un temps de down. Oui, mais c'est Kiklog, donc ne vous inquiétez pas. C'est pas un service public face. Je suis désolé. Je ferai le temps. Pas de problème. Réalignons l'availabilité, donc nous avons rencontré GIFROG la semaine dernière. Je vais partager les notes. Donc, ils doivent encore venir nous pour la migration de la migration de l'infrastructure de l'availabilité. GIFROG nous a réveillé pour la nouvelle service SASS qui a donné un peu plus de métro. Ils sont plus tard sur le processus par rapport aux raisons humaines. Mais il y aura un outage. Donc, il y aura un outage qui va prendre un peu de temps. Donc, je leur ai dit, si ils ont besoin de l'availabilité, ce n'est pas un problème. Comme nous le savons, c'est assez tard d'assurer que nos utilisateurs connaissent. Donc, nous n'avons pas essayé d'établir la sécurité, c'est un jour, bien sûr. Ils préfèrent si ils prennent leur temps. Parce que ça pourrait être assez le problème. Donc, ils nous ont dit qu'ils nous ont dit qu'ils feront de la migration de l'availabilité. Ils feront de la migration de l'availabilité de l'infrastructure de l'availabilité pour un mois. Ce qui veut dire qu'à un moment, si ça se passe, nous pouvons toujours falloir le nom du domaine de l'availabilité. Alors, disons, s'il vous plait, malheureusement, si c'est une chance pour la migration, pas vraiment pour la migration, c'est-à-dire, que nous pouvons faire, pour que nous prenions des Etats-Unis, que la migration soit dans la opération de l'availabilité. Et si on a une correction ou si nous perdons les données sur les nouvelles instants, nous pouvons toujours régler la toute l'instance. Le deuxième point de la question C O, on peut enlever l'authentication. Marc et Damien pour faire un acte pour trouver une bonne banque. C'est un issue de priorité, comme un issue de priorité. C'est pourquoi Marc et moi travaillons. La première priorité est l'application de l'application IP, qui est toujours importante et toujours est liée à la banque du chiffre. Nous allons aussi travailler sur l'availabilité de l'application LDAP, au moins la réplique réplique. Parce que par l'authentication d'availabilité, cela signifie que nous avons eu plus de pression de service et de qualité de service. Donc, LDAP n'aura pas accepté la même banque d'authentique que l'application d'availabilité. Donc, nous devons trouver une solution de l'application. Externel DNS pour le cluster de Kubernetes avec un ingress. Est-ce qu'il y a quelqu'un qui est intéressé en ayant le temps de le faire ou peut-être que nous devons le remettre pour le backlog ? Je pense qu'il peut rester dans le backlog, on n'a pas d'immédiatité pour maintenant. OK. Vous avez d'autres issues que nous devons parler ? Vous avez d'autres issues qui arrivent, qui ne sont pas les backlogs aujourd'hui, Oui, c'est l'un que j'ai commencé, le cluster de Kubernetes privé. Absolument. Oui, on l'a mentionné, mais je l'ai oublié. Donc, celui-ci, il faut le mettre pour le prochain. Oui, j'ai commencé. OK. Donc, le plan, juste un souvenir, peut-être une note pour Mark, parce qu'on a discuté ce matin. Donc, maintenant, nous avons Prod Publicate, qui a l'application IP, le cluster de production, et aussi l'ACP host. Et nous avons Temp Private-KRITES, qui est un cluster de Kubernetes privé, où l'infrascii est en train, et seulement l'infrascii. Il y a beaucoup de services, il y a des certifications, donc il y a des services de site. Donc, le but est d'abord, nous créons un Teraform Managed, un nouveau cluster Azure, qui s'appelle Private-KRITES. Nous migrons l'infrascii, et nous pouvons retirer Temp. Ensuite, nous migrons toutes les services du Prod Publicate, qui devrait être sur la nettoire privée. La principale, c'est de relise.ci. La raison est qu'on ne veut pas relise CI et on ne veut pas relise la nettoire privée, bien sûr. Donc, ça pourrait avoir des impacts, mais je ne pense pas qu'on va avoir beaucoup, parce que le VPN, maintenant, c'est une grande machine virtual qui a accès à la nettoire privée pour aujourd'hui. Nous avons aussi un peu de services dans le Prod Publicate, qui devraient être élevés dans l'arrière privée. Tous les bots, pour exemple, parce qu'ils n'ont pas besoin d'incompréhension. Ils n'ont pas besoin d'incompréhension. Ils n'ont besoin d'agresse. Donc, celui-ci devrait absolument être sur la nettoire privée. Au moins, nous voulons définir une catégorie d'infra-users qui ont accès à la nettoire privée. Mais au moins, la nettoire privée Grafana, Rometheus et Infra devraient être sur la nettoire privée. C'est le premier step mandatoire. Le but c'est d'avoir le premier teraforme managé dans votre cluster. Parce que c'est le dernier cloud qu'on n'a pas managé avec un teraforme. Nous avons déjà fait ça pour Digital Ocean et Amazon. Alors, Airways a commencé à préparer le travail sur ce sujet. Parce que, si nous avons créé des catégories privées et migrées, nous pouvons créer ce qu'il devrait être le replacement pour les publicités privées, mais il ne devrait pas avoir l'application IP et il devrait être correct en termes de recommandations Azure. Le cluster currently est créé 4 ans auparavant où Azure n'a pas donné autant de features aujourd'hui. Maintenant, Azure a changé beaucoup, donc nous devrions changer des éléments. L'une des principales improvements en ce secteur, que Airways a pointé aujourd'hui, est pointée par l'équipe quelques mois auparavant. Nous devons arrêter d'utiliser le principal service qui est un système technique avec un token qui permet aux Kubernetes de connecter à l'application Azure à l'autoscale, à des volumes, à l'assurance Azure. C'est un compte technique pour l'application. Un équipe nous a dit qu'il y a un système différent, je pense que c'est une identité comme le système IAM sur Amazon qui évite d'attendre un token et d'arrêter un token. Il utilise l'instance base d'identité pour identifier. Et celui-ci est maintenant en utilisant l'ID afin que c'est le même niveau de sécurité que l'Amazon. Alors Airways est currently expérimentant tout ça à l'application Azure. C'est-à-dire qu'il y a des outages d'infra-ci et dans le futur et toutes les autres services pour migrer à un nouveau cluster. Quand tout est migréé et qu'on n'a pas plus d'IP de l'application Azure, nous pouvons retourner à l'ACP. Et nous pouvons monitorer que tout va bien avec l'AZP. Oui, absolument. Oui, DataDog est marcher parce qu'il a pointé les issues de network pour nous. Oui, c'est-à-dire que c'est pas marcher, mais c'est marcher. Absolument. Airways, n'est-il pas marcher? Cool. Alors Airways lead cet area. Et nous verrons si nous avons les derniers minutes d'un nouveau topic. Je pense que c'est déjà beaucoup. Marc et moi fichons Gifrog Ripot. Airways fichons le nouveau repository et le général maintenance de l'ACP. Et Stéphane et moi travaillons. Quand Stéphane est terminée avec la migration des clés, nous travaillons sur le pipeline de Jenkins, ou unifié pipeline. Un file de Jenkins pour un projet qui va faire les builds de CI avec des outils visibles et actionnables. Et seulement le port de déploiement sur Infra-CI. Pour moi, est-ce qu'il y a quelque chose d'autre qu'on veut ajouter? Nous verrons le 15 novembre. Comme reminder, le 11 novembre est un jour de banquement national. Je pense que Stéphane, Hai et Dervé ne vont pas marcher cette soirée. Et nous devons faire le meilleur d'assurer que vous ne travaillez pas cette soirée. Merci beaucoup. Ça peut être un jour réel. C'est un jour de banquement national. Je vous remercie pour vous d'avoir regardé cette semaine. Je vous remercie pour la première fois. C'est bien de vous pour vous. Je vous remercie pour la première fois. J'imagine que vous devez faire une série