 Hello everyone, welcome to the Jenkins Infrastructure team meeting. Today we are the 19th September 2023, and around the table we get myself Demian Duportal, Mark White, Stefan Merle, Bruno Verrarten, and Kevin Martins. Looks like our Erwelemer looks ill, so I will try to speak on his behalf for the task he worked on. We try to share a bit of information, mais depuis que j'ai été au Huff pendant la semaine dernière, je vais essayer notre meilleur. On commence avec l'annoncement du week-end, pas du week-end cette semaine, pas du week-end aujourd'hui, parce que demain, le score de Jenkins de sécurité et de l'adviserie sera publié. Il a été annoncé, c'est public et officiel, parce que le score de l'adviserie est à l'heure de l'hôtel et du week-end. Donc, le processus de relance automatique a commencé, mais a changé de ne pas performer. Alors, comme Stéphane Haï a checké cela aujourd'hui, il n'a pas rendu le relance comme prévu, mais en utilisant un erreur prévenu, plutôt qu'une écho de message et d'erreur de la pipeline, il y avait un erreur prévenu par le message écho, pas sur le bloc proper, mais il a fait le travail prévenu, donc c'est ok. J'adore quand un plan vient ensemble. Je l'ai regardé, l'autre jour, très bien. C'est la façon dont le quote de l'A-Team. Merci Damien, culture référence. Pour les deux Français, j'adore quand un plan se déco-roule sans accro. C'est exactement ce qu'il y a. Je vois que nous avons un peu de connoisseurs ici. Vous avez un annonceur, les gens? Ok, je n'ai pas un annonceur, oui. C'est le 21 juillet, et il y a une live qui se passe aujourd'hui. Oh, c'est génial. Oh, ce qui se passe. L'aujourd'hui, il y a des live streams et tout sortes de choses qui se passent à l'annoncer. J'ai un problème, je ne peux pas... Ok. J'ai perdu ma capacité de type sur le documentaire. L'aujourd'hui. Ça veut dire qu'il y a plus de travail pour Stéphane et d'Hervé? Oui, il y a. Et Bruno? Oui, Bruno et Stéphane, oui. Il y a Hervé aussi, oui. C'est tout le travail pour vous, les gars. Merci. D'autres annonces? En question? Non? Ok, donc la prochaine semaine est demain. Je crois que ce sera... Je ne me souviens pas le numéro. Je vais... J'ai utilisé ma chechette, ce qui est... Les notes dernières, ce sera 2,423. Et demain, il y aura aussi une release LTS, ce sera... 2,424.2. C'est correct? C'est correct. Donc, comme on dit, l'adviserie demain. Ce sera public. Je vois les emails, je vais avoir le lien sur les notes, ce sera plus facile pour tout le monde. Qu'est-ce qu'il y a? Deux grands événements. On a Dévops World. Ce qui s'est passé la semaine dernière. Je crois qu'il y a un épisode en octobre. Est-ce correct, Marc? Oh, Chicago, le 1er septembre. La prochaine semaine. Oui, septembre, je veux dire Chicago la prochaine semaine. Santa Clara est, je pense, en octobre 2020. Oui, on a un événement en octobre. C'est cool, on a London en fin novembre 2023. Je ne me souviens pas de la date exacte. C'est vrai. 29. 49? 29, il n'y a pas d'événement. Il ne marche pas, c'est vrai. Ok. Et la première semaine sera en Brasov. La prochaine semaine, 3 et 4 février. La première semaine, en février, comme d'habitude. En Brasov, un beau vent, comme d'habitude. Avec un mélange de soleil, de l'air et de l'air. Comme d'habitude. D'autres événements principaux ou des événements calendaires? Ok. Oh, le fest octobre. C'est vrai, oui, bien sûr. Oh, oui. Le fest octobre commence en octobre 1. Il conclut en octobre 31. La première semaine, jusqu'à 31. Oui. Donc, merci, Sérviant et Stéphane, pour continuer à soutenir les problèmes qui pourraient être les premiers numéros pour Jankin, Sinfra, pour notre participation en fest octobre. Nous pouvons continuer si vous avez question sur ce sujet. Nous n'avons pas écrit un document, ce qui pourrait être une bonne chose à avoir. Si on veut un document public sur le fest octobre, nous pouvons peindre sur les problèmes qui pourraient être intéressants. C'est un sujet. Nous allons ajouter un sujet sur le fest octobre, est-ce que c'est ok pour vous, pour que nous puissions ajouter le travail sur celui-là? Oui, c'est mieux de le faire maintenant qu'une semaine de maintenant, et nous devons être plus pressés. Fest octobre. Fest octobre. Le procès des laboratoires. Ok. Qu'est-ce qu'on fait? Oh, merci. Donc, peut-on procéder sur le procès des laboratoires? Oui. Ok. Donc, qu'est-ce que nous pouvons terminer durant le passé mi-lestone? Nous avons trois soucis de l'issue, et un soucis de l'issue qui n'a pas été ajouté par l'utilisateur. Je l'ai ajouté ceci aujourd'hui, parce qu'après les marques et les travaux, il n'y a pas d'answer de l'utilisateur, excepté le message de la première étude avec aucune information. Donc, je ne sais pas ce qu'est le problème, et si on peut aider. Donc, c'est pourquoi j'ai décidé de la clé. Bien sûr, l'utilisateur peut l'ouvrir, comme usual, mais sans information technique, c'est unclear ce que nous espérons. Un délai long d'expects, vous vous pliez un bâtiment de biomarchie, test-free-buckets. Donc, plus, il ressemble à ce que J.C. Glick était correct, sur le fait que il a appris dans un outage AWS S3, qui expliquait les longs des temps de bloc. Mais, c'était l'opportunité d'améliorer un délai feature sur l'agent C.I.G. dans l'I.O. pour attirer le comportement de la modélisation de pipeline, quand le contrôleur ressemble alors que les pipelines sont en train, surtout dans le cas de BOM. Ce que nous avons vu, c'est qu'il n'y a pas de régression. Nous n'avons pas de table pour démonter bien, si il y a un effet sur les performances. Mais le temps de bâtiment de la single BOM est environ 3 heures et 15 minutes, presque 4 heures. Ce qui semble qu'il n'y a pas de constance ces mois. Un peu d'incrédence parce qu'on a fait plus de tests. Mais nous n'avons pas vu de grandes différences. On voit quand un set de blocs parfaite parfaite que tous les concurrents de l'SH et de tous les agents ou des stations d'opération sont des fois. Mais, oui, le stash en stash ressemble à ce qu'on a. Donc, pas de régression. Et le problème initial de cette issue est fixé. Est-ce que c'est le même pour toi, Marc? Est-ce que tu apprécies avec cette résolution? Oui, mais j'ai eu surprise. J'ai launché un BOM bâtiment environ 12 ou 14 heures et ça a été terminé après environ 8,5 heures de tournage. Donc, ce n'est pas un monde parfait, mais ce bâtiment, comme je peux le dire, je dois encore analyser ce qui a causé ce ultimum fail. Il a réporté plusieurs résultats positifs. Et je pense que c'est... Oui, ça n'est pas... Je vais le faire again parce qu'il y a des changements dans le bâtiment de matériaux qui sont récemment arrivés, que je veux évaluer, donc je vais probablement faire un autre bâtiment de matériaux plus tard aujourd'hui. Ok, j'ai vu deux improvements sur le court terme que nous pouvons faire. Donc, j'ai eu mon long bâtiment de tournage en essayant d'utiliser plus de machines pour avoir beaucoup plus de pôtes. Mais en termes de costes, nous avons vu que ce bâtiment n'était pas changé ou l'a augmenté les costs de chaque bâtiment. Donc, je ne suis pas sûr que c'est la meilleure solution jusqu'à ce qu'un problème de concurrence s'occupe dans l'internel de Jenkins, mais c'est vraiment difficile de comprendre le problème. Mais, nous pouvons appliquer le même bâtiment que ce que Stéphane a fait sur le ATH. Je vois que, souvent, nous avons beaucoup de réclaims de spot-instance qui lead à l'agent s'y retirer. Ce bâtiment s'enlèrent. Je ne sais pas si il s'enlèrent 1% x 5%. Je ne sais pas les effets, mais avoir un système qui change les tags d'un bâtiment d'un agent de spot-instance à un agent d'un dément d'instance serait intéressant de voir si ça a un effet dans ce cas-ci. Le effet est plus facile de voir sur le ATH parce que ce sont les machines donc le rétrait est immédiat. Dans ce cas, depuis qu'on a un niveau de direction nous cadulez les pods sur différents clusters avec différents labels et ensuite, nous avons l'autoscaling derrière. Je ne sais pas si l'effet sera aussi facile de mesurer, mais ce serait bien d'en essayer. Il y aura un peu plus d'efforts pour mettre en place, je ne sais pas si c'est valide. Qu'est-ce que tu penses ? Oui, je n'y suis pas. Je comprends. C'est une idée possible. Je pense qu'on ne doit explorer cette idée maintenant juste parce que je pense qu'on a plein de choses qu'on peut faire pour dealer avec le comportement currently. Ok. Il y avait plus de plantings qui n'étaient pas vraiment appelées pour l'action. Great. Les issues de certification de la SSA ont été élevés. Donc le problème est que il y a eu des confusions depuis deux années entre quel component entre Fastly et notre cluster public est mené certifier et recevoir des requises pour le domaine Apex Jenkins.io. www.jenkins.io point à Fastly. C'est un fact et le certificat est managé par Fastly en point. Dans le cas de Jenkins.io il y a eu plusieurs fois et afin de remettre cette confusion depuis le dernier change en termes de DNS quand l'HRV a travaillé sur migréant pour le nouveau cluster. Nous avons décidé comme équipe de changer le Apex des requises sont envoyées au cluster qui directe Fastly sur www.jenkins.io donc ce n'est pas beaucoup de workloads donc c'est OK. C'est seulement l'HTTP redirect. Ce qui veut dire qu'on termine TLS pour Jenkins.io Apex domaines sur public gates. Donc afin de résoudre cette issue après confirmant que Jenkins.io était le culprit pour certifier les certifications dans le cluster automatiquement. L'ordre était là c'était traînant mais en passant pour créer le challenge ACME dans les records DNS parce que le record DNS était appris par Fastly. En retirant toutes les références sur Apex domaines sur Fastly maintenant, tout est managé du cluster public et le réunit automatiquement. Ce qui veut dire qu'on doit vraiment commencer d'éliminer ce doigt et que comme nous l'avons dit deux semaines auparavant ce qui pourrait être une bonne fête actuelle. Ce doigt est déjà monitoré le certificat SSL quand ils sont expiés. Donc ça veut dire qu'on doit étudier tout le même que ce que vous faites en étant capable d'avoir ce doigt pour que nous puissons dire 25 jours avant avant les expiés ce doigt s'éteint. Est-ce qu'il y a une question sur ce topic ? Non. Ceci est un truc Merci pour l'analyse détaillé. Tout est sur l'issue. Merci Stéphane pour déclencher l'analyse SPF ce qui n'est pas un problème SPF comme vous l'avez décrit donc l'issue est très claire parce que c'est dépendant d'un processus d'analyse sur Google ou gmail est-ce correct Stéphane ? Exactement. C'est cool. Je comprends des choses sur les emails. Waouh. Ouais, ne dis pas ça trop vite. Tu n'en sais pas. Ok, donc maintenant l'issue marche en progrès. Je vois que l'arrivée est capable de rejoindre. L'arrivée est-elle ok pour parler ? Vous voulez que je parle de l'arrivée sur Google sur le Centre d'updates ? Je ne sais pas. Je me suis terminé d'activer un message pour l'updater. Oui, je peux... Donc nous sommes maintenant sponsorisés par Cloudflare qui est une excellente news. Italo a besoin d'utiliser deux bouquets qui sont comme S3 de AWS avec 3 agresses qui sont pourquoi nous avons choisi le premier. Nous avons installé l'initiel d'arrivée d'arrivée donc nous pouvons utiliser l'arrivée d'arrivée pour créer une source Cloudflare. Nous avons maintenant créé un procédé et un procédé de la Chine de la Chine via Cloudflare avec un en ligne et l'autre en en ligne. Nous allons ajouter ce procédé et la terraforme qui peut configurer la Chine de la Chine de la Chine de la Chine et le reféter cette configuration. Nous allons commencer le premier procédé d'arrivée d'arrivée de la Chine d'arrivée d'arrivée on arrive à créer des sources qu'on veut qui sont plusieursiseries d'arrivées dans les régions les propos et la zone de plate-flair qui sont des records NS, comme l'Europe ou l'Europe de plate-flair en Stataillot. Nous pouvons associer ces records à ces spaghettés et nous pouvons obtenir des updates de plate-flair en Stataillot, dans plusieurs régions. Nous refocussons des records de plate-flair en Stataillot, nous avons des sponsorships et nous sommes en train de faire des documents de plate-flair en Stataillot, nous pouvons travailler en parallèle, mais le but de l'air c'est de faire des updates de plate-flair en Stataillot depuis qu'il n'y a pas de plate-flair en Stataillot. Nous voulons diminuer les records associés à ces instances, ce qui est le troisième de nos records de plate-flair en Stataillot, le troisième de l'alphabet de l'Irlande. Je pense que c'est le troisième, oui. Je vais poser des updates sur l'issue. C'est clair, est-ce qu'il y a une question, une clarification sur ce topic ? C'est-à-dire que c'est ok pour continuer de travailler sur ce topic dans la prochaine milestone de l'arrivée ? Oui, c'est sûr. C'est clair, c'est obvious, mais j'ai préféré le demander. C'est un bon travail, très heureux avec les outils, donc on devrait pouvoir avoir quelque chose bientôt. Bon travail. Vous pouvez laisser le meeting si vous vous sentez mal physiquement, ne vous inquiétez pas. Merci pour prendre le temps pour partager votre progrès ici. Il y a quelque chose à ajouter ? Comment pouvons-nous bouger sur le next topic ? Nous pouvons bouger sur le next topic. Cool, merci. Le next topic, par priorité, c'est l'artif de l'artif de l'artif de l'arrivée Je ne sais plus si vous avez le temps de vérifier les outils de l'artif, pour voir si vous avez l'effet de retirer le mirage. Je n'ai pas, j'ai capturé les outils, mais je n'ai pas analysé. C'est pour moi. Ok. Mais pas encore. Bien. Ok, sur mon côté, je suis toujours bloqué sur le MAVEN HPI plug-in. Merci pour l'aide de Basil. Merci beaucoup pour les pointeurs. Il s'agissait que la stratégie initiale qu'on avait à fixer l'intégration test ne marcherait pas comme expected. Donc maintenant, nous explorons d'autres options. J'admite que je suis un peu perdu. J'ai essayé beaucoup de choses basées sur le MAVEN official et tous les outils de ce projet. J'ai essayé le corps du problème, c'est que nous avons été l'horreur de ce problème, c'est que nous avons des erreurs sur CI Genkin-Sayo qui sont vraiment difficiles de reproduire localement, mais je ne comprends pas pourquoi. Je pense que j'ai quelque chose. Ça ressemble à la façon dont le MAVEN local repository plug-in merge les files XML dépendant de la façon dont les files XML sont appelés pour l'outil MAVEN en vocation. C'est pour ça que j'ai tendu à mettre les files. Mais en fait, sur CI Genkin-Sayo, nous ne faisons pas ça. Nous changeons l'environnement variable MAVEN underscore quelque chose et nous spécifient un extrait de flag, comme dash s et le pass du file temporel de la file XML. Quand MAVEN, le top level MAVEN est invoqué, il automatiquement read la variable et complément les flags. Ce qui veut dire que quand vous read les outils de la file sur CI Genkin-Sayo, vous ne voyez pas ce flag. Vous ne voyez pas le dash s explicitement, parce que c'est un internal de MAVEN. La seule façon de voir c'est de rouler MAVEN en debug mode ou de rouler un pompe d'effectif qui va prendre l'account de la file XML. Et il s'imagine que je peux reproduire le problème de la forme sur ma machine. Mais si j'utilise le propre setting de la file XML sur une location différente, c'est correctement correct. Ce qui sentait comme un bug ou un behavior de l'AMRM plug-in. C'est le statut où je suis bloqué. J'ai besoin de continuer l'analyse, mais ce n'est pas facile de fixer les tests de l'intégration. En même temps, on va fixer les ITS. Je pense qu'en fin de compte, on peut vouloir dégager l'ACP pour ce projet. Ce serait une solution. Je n'ai pas testé cette solution, mais c'est possible d'élever l'ACP juste pour le MAVEN HPI plug-in. Marc, je ne pense pas que la fréquence de builds sur cette solution va être en danger avec des downloads. Mais je ne peux pas être sûr de ce que c'est votre vue sur celle-ci. Je ne pense pas que c'est un danger à la fréquence. Mais on veut fixer ça. L'option de l'ACP pour le MAVEN HPI plug-in serait bien. Si ça se résulte même temporairement, c'est une bonne solution. Pour être assez honnête, j'ai parlé d'utiliser l'ACP pour le MAVEN clean package state. L'option de l'ACP n'est que pour le stage vérifié. Cela signifie que que les tests de l'intégration avec l'ACP sur le pipeline pourraient aider à bypasser le problème. Mais c'est le fall-back. Je préfère le servir. Pour moi, si l'option de l'ACP pour cet exemple résolve que nous avons d'autres choses qui nous ont été opthées, si ça fonctionne, on le appelle bien. On va probablement avoir de la solution plus tard. Mais je suis bien en train d'opter pour l'un des choses. Merci pour le feedback. J'aime le guide de Basel qui a parlé avec l'un des maintenance de l'ACP. Ils ont adhéré de l'AMR plug-in. J'ai l'impression d'utiliser des trucs qu'on a besoin. Le problème est que Basel, comme moi, a découvert que l'erreur est toujours présente même sans l'AMR plug-in. Donc, nous devons stabiliser l'IT avant de penser à le garder ou à l'utiliser. C'est tout pour l'artifactoire que j'ai gardé. C'est une action pour nous de fixer l'HPI. Marc, on va rencontrer GFrog pour voir avec eux l'effet qu'ils peuvent voir. Je ne crois pas que c'est... Je ne crois pas, mais je vais voir et je vais trouver parce que j'ai l'impression que c'est sur nos calendaires. Est-ce qu'il y a d'autres questions sur l'artifactoire? Je ne vois pas sur un calendaire, mais je pense qu'on a fait un plan. Je ne suis pas sûr. Peut-être pas. Je vais vérifier l'artifactoire. Cool. Ok, Stéphane, votre turn sur les services répliqués sur les clusters publics. Affinité et PDB. Can you give us a head up on this one? Affinité on didn't really catch. Our main problem is that for IAM64 we have only one node and the auto scaling of Azure is not triggered and doesn't scale up to 2 when we set the anti affinity. I did try to add the pod disruption budget to enforce that triggering and it's still not triggered the second node. I am thinking of forcing the minimal number of node to 2 on the auto scaling in Azure at least for the IAM64 but I think for everyone will be good enough too and to enforce everywhere we have more than one count instance pod instance to have at least the PDB and not affinity to make sure that if we have to recycle a node every application with 2 instances will still be working on others nodes. Anti affinity and PDB to all replicated service for better QOS. Oh yeah, perfect. Thank you. The explanation on the work. Is there any question clarification needed on that topic? Ok, so I believe you will work on that topic and we keep it on the next milestone. Is that correct? Yes, please. Cool. We had the new that one is a new topic. It was added between last team meeting and now that's why I'm putting not a big just finishing, remove account request fill from Jeralogin page I didn't have time to look on to this someone a contributor propose help I'm not really sure what to do I won't have days of this week so I might have some time to spend on this one and ask other for help. It requires Jenkins admin. Stefan your turn for the two last one RM64 migration of services That's on hold because we don't want to to migrate application that could be disrupted by a recycling so first anti affinity and PDB and SQL to auto-scrilling before keeping the migration OK and I might also prioritize the change on the shared pipeline library to have only one pass on main instead of main and tag to publish the images OK save cost and time Please pipeline library optimum I believe I comment on this one I'm confusing with another I believe you had the list of the potential services that could be migrated to RM64 I did that week already and that list was not exclusive no exhaustive because I missed the post you remember that but that was already OK so I propose that we don't move that issue to the next milestone we move it back to the backlog yes sorry if we already decided that and I added this week milestone I should have moved it last week so I will be careful that time and Matomo what's the status that's on your side I draft a pull request and some comments in the issue to think a little more on how we choose the MySQL instance and what option we select or not OK and I believe that's the same it was on hold waiting from team feedback and for the image I believe it was on hold you started cleaning up the repository I don't remember so it's not that week it was week before OK you have a status OK so now if you're still here and still OK let's go on the new issues that we've added since last meeting on the current milestone in that case removing pages of Jenkins IO when we deploy a new version removing the pages that are not part of the new build anymore it's another issue we've put in the background but since there has been a few new issue on Jenkins that IO with people noticing that all pages were still there Spinec has opened a pull request to add the delete to the Blobixfair command but to be sure we will not lose content I've first I've made a snapshot I've put in place a backup of this storage account which is an Azure file storage Azure file share I'll have to check next week and the week after that if it's costly or not but since the content is less than 500 megabytes I don't think it will be a lot I've then compared all file from this storage account from the file generated from a clean build of Jenkins.io I've posted a list in the issue and Spinec has commented on it most of these difference seems ok but there is also some documentation about library which are not here probably because of the issue of the backend extension indexer not just probably highly confident that that's the problem so I've asked in the issue if we should resolve this issue first the two reserves the backend extension indexer issue need more work size it would require refactoring of the backend extension indexer or a complete rewrite of it I saw some ping-pong between some Jenkins maintainer I don't know really where what's the state of it backend extension indexer correct ok so is my understanding correct on what I wrote that the backend indexer thing is blocking no no so I'd argue a different thought process there the backend extension indexer is broken and is becoming progressively more broken all the time because the brokenness is injected every time a plugin uses incrementals it drops from the indexer right now it's a good way to find old plugins also remaining plugins right I like airvays you should be in marketing that was a brilliant marketing answer that was absolutely wonderful yes it's a great way to find old plugins so yes it's already broken Jesse Glick a offered an alternative that will be much much faster in terms of the generation process and is much smarter about doing the generation right now that thing is very heavyweight so part of me wonders if we should choose to disable the backend extension indexer completely and then queue up a task for Hacktoberfest to rewrite it it's maybe a little useful right now but becoming less useful all the time ok so maybe this is one where we put it on Bruno and me to say maybe this is one we find a way to put into Hacktoberfest ok so airvay so if I understand correctly then with your explanation that mean there might be some tasks to the Jenkins.io maintainer to finish checking what will be deleted and then we can proceed yes I'd like another opinion about I'm not sure if I pronounce it right but he seems confident but I'd like another opinion about his comment on the list to be sure we can activate the delete option ok I agree with that we do want more opinions I was worried about the redirects file so there are some files in the list of deleted files that I think need to be very carefully viewed to see should this be deleted true that the .htac is right that's what it was .htac yes thank you I'll try the diff with an option filename case but I don't know why I have more results so yeah and the .htac s I'm wondering I'm not sure the .htac s is a problem more because fastly is not using this right it might be a I'm remnant from before and it's engineic so in any case it's not working anymore is that correct well and I like that that's a great answer that's an answer that my ignorance of who uses .htac s would never have answered so you're giving a great answer if that's only used by Apache servers and we've long ago stopped using Apache servers to serve this site then no problem yeah I believe so be careful because we could block a lot of pages if you want to do the diff on your site I'd like that to be sure a second ok as I said I think I'm ignoring the filename case I have more results in my diff so I'm not really really confident in my analysis I'd like a second one no problem mkops is me probably in your part cp-er of the current bucket content to burgers and if anything goes wrong we have a copy so the initial state without waiting for a new site bit I don't mind checking on my Je pense qu'on a besoin d'une autre vue de quelqu'un qui mérite les pages de Jenkins.io parce que je n'en sais pas le lien entre A-Docs et les pages. Je pense que j'ai la même vue que toi, ou même un autre vue que toi, mais je n'ai pas l'aider. La seule question que j'ai, c'est que j'ai préféré que nous planissons l'opération, donc nous annoncerons que nous serons sur le site de Jenkins.io de status Jenkins.io, juste d'être double sûr que si il y a quelque chose qui se passe, oui, mais ça va être annoncé. Est-ce que c'est OK pour toi, Réveil ? J'aime votre suggestion. Je pense qu'on doit mettre sur Kevin Martens, ou Kevin Martens et moi, la responsabilité de faire le look du côté de l'opération, parce que, hey, Kevin est l'opérateur d'A-Docs, et j'ai eu l'expérience avec l'opération, donc, on va mettre, il et moi, comme les uns pour faire le check-up. Si ça peut aider, on peut aussi réworker ses listes. Donc, en tout cas, si j'ai un nom, il sera un nouveau RL, on peut cliquer sur le check-up. Oui, Kevin et moi, on peut écrire ce genre de choses, mais merci, Réveil, que le scripting, ça ne me sent pas comme un problème. OK. Ça pourrait être plus cher de déployer un site temporaire. Est-ce que c'est ce que tu veux, Réveil ? Non, je m'ai juste dit... Dans la liste, il y a une liste de folders en file, et je vais juste transformer ça dans l'urale, par ajouter fttp slash slash Jenkins.io slash, le nom de la folder slash, le nom de la file. Donc, ce sont les items de cette liste qui ont été décalés. OK, parce que je pense que ça serait assez facile de spanner un staging.jenkins.io service qui sera servie par les mêmes assets. C'est seulement un virtuel host pour ajouter une règle ingressée, et ensuite on peut essayer le déployement en parallèle sur les deux. Je pense qu'on a déjà des assets. Avec le stage... Si on a des requests sur Jenkins.io, j'ai toujours créé un site de staging sur le verset, ou je ne sais pas si... C'est correct, c'est un site de staging sur Netlify. Oui, sur Netlify, oui. Nous avons déjà des websites de staging pour comparer. C'est correct, c'est pour ça que nous pouvons prendre une récent pull request, et si tout est faible par Netlify, c'est à dire que c'est faible quand nous serons sur le dash-delet. Bon point, bon point. C'est à dire que nous pouvons déjà commencer le travail de l'analyse dans l'environnement déployé. Ok, donc je vais avoir celui-là sur la nouvelle milestone. Est-ce qu'il y a quelque chose d'autre que ça ou... Non, c'est bon. Ok, donc vous devez proposer une planification sur la date, si vous ne voulez pas déployer les next steps. C'est votre choix. Et en tout cas, je vais répondre à votre call pour l'aide pour un second purifier sur la partie technique. Est-ce que c'est bon pour vous ? Oui. Marc et Kevin, nous avons besoin de votre analyse sur le déploiement de récent pull request sur Genkins.io pour voir si il y a des choses qui sont faibles sur ces sites prévus. Ok. La prochaine question, Stéphane. Vous avez créé l'issue de speed-up sur le library d'images d'images. Est-ce que vous pouvez nous rappeler le but et pourquoi vous voulez travailler sur ça pour maintenant ? Je découvre que quand je travaillais sur le library d'images d'images sur le DOKER bake, l'image d'images. Et en fait, c'est un processus de deux rounds. La première, le but du main, est de construire les plus tardes. Et c'est de produire un tag, un tag GitHub, qui traite un autre build sur le site tag d'images d'images. Et ce pass, ce temps, c'est de produire le tag d'images d'images et d'Oka Hub. Nous pouvons coller ces deux en seulement un et le premier stage du main. Et puis, on peut aussi faire un CPU pour l'autre. Et aussi, peut-être moins un github de rate limit que nous avons découvert qu'on a fait ça très souvent et que ça va résoudre notre temps aussi. Ma main préoccupation sur ça, c'était comment prendre un tag manuel, comment ça va traiter un tag manuel si on a retiré l'automatique pour traiter les tags. Donc, tu as répondu, je suis désolé, je n'ai pas obtenu tout l'extérieur de ta main. Donc, nous devons parler de tout ce que j'ai pensé sur le problème. Un tag github à traiter. Donc, l'idée c'est que d'abord, nous devons tous comprendre qu'on a une découverte à traiter quand vous avez un tag dans les Jenkins. Les deux nécessitent une configuration spécifique. Aujourd'hui, nos images d'Oka et les ICI sont toutes setées pour les deux. En découvrant un tag, c'est-à-dire, quand vous recevez un webbook, vous scannez l'opposité et Jenkins dit, oh, j'ai vu un tag. Et il crée un pipeline sur le tab de le pipeline multi-branche. Il crée un pipeline pour ce tag, mais il ne crée pas par défaut ce tag. Le but c'est que si vous migratez à Jenkins et il scanne l'opposité de nouveau, par défaut, vous ne devriez pas tenter de rebuilder tous les tags, ce qui fait sens. Donc c'est la découverte. Et ce n'est pas un problème. En tout moment, un utilisateur peut manuellement aller à un tag et traiter un build. Si nous focusons sur ce point, c'est-à-dire, ce qu'il faut comprendre sur le pipeline et l'élaboration c'est le fait que si l'environnement variable le tag est set, vous pourriez avoir un comportement spécifique. Comme, oh, en ce cas, je le savais déjà, la version réquestée par l'utilisateur. Donc je ne vais pas traiter l'automatique version de la détection. Et je vais utiliser l'environnement variable de la tag ou de la tag ou de cette variable qui est set. Si ce n'est pas un set, c'est-à-dire que vous êtes sur un build principale. Et en ce cas, si c'est un branch principale et ce n'est pas un set, vous automatiquement détectez l'utilisation de la version GX comme nous le faisons aujourd'hui. Mais cela signifie que nous allons premièrement déterminer sur l'infratag l'automatique de l'automatique. L'automatique de l'automatique est une configuration additionnelle de l'itemtre qui dit oh, si vous découvrez une tag et cette tag pointe à un commit qui est nouveau et trois jours plus âgés, puis automatiquement un build de l'automatique. Et ce n'est pas ce qu'on veut. En tout cas, quand vous puissiez la tag de l'utilisation de l'automatique, ce qui va rébuilder la même tag et ce qui va être un loop. C'est ce que vous arrêtez. Vous vous retirez ou dévoilez cette configuration de l'automatique de l'automatique. Je vous donne un lien sur l'itemtre de l'automatique de l'automatique de l'automatique. Ça devrait être actionnable pour vous. Mais c'est l'idée. Je peux être d'accord. C'est la première analyse. Et peut-être que je n'ai oublié quelque chose. Mais je crois que votre question est la meilleure. Parce que nous devons toujours réserver la capacité d'établir un bâtiment manuel. Ça devrait être rendu par la pièce et l'article. Mais ça sera seulement un cas rare. La plupart du temps, ce que notre main target est c'est qu'on fasse le bâtiment main. Et ça va automatiquement créer un nouveau tag. Je crois que la partie plus importante commence par dévoiler une fois que vous avez préparé la requête d'automatique. Vous devez dévoiler tous les jobs. Vous pouvez commencer sur le travail de la documentation que vous voulez tester. Et ensuite, nous pouvons générer avant d'améliorer. Nous pouvons dévoiler où nous dévoilons le bâtiment. Ok, cool. Exactement. Et mon proposo est que votre première version devrait même fâcher sur le tag. Fâcher comme si c'était le bâtiment main et qu'on veut un nouveau bâtiment qui traite le bâtiment main pour qu'on fasse un nouveau tag. Nous commençons avec ce bâtiment. Et ensuite, nous implementons le support du tag seulement si on voit qu'on a besoin de ce cas. Parce que je ne crois pas qu'on a eu ce cas depuis des mois. Ok. Est-ce que l'answer va faire surement de commencer le bâtiment mais ça semble être, oui. Cool. Merci. Nous allons sans le process de tag. Est-ce qu'il y a une question de clarification sur ce sujet? Nous ajoutons le bâtiment suivant. Oui, s'il vous plaît. Cool. Une nouvelle issue que j'ai faite sur le milestone et je vais travailler sur ça. Nous avons quelqu'un de Telenet qui est une partie de l'organisation BellNet avec un sponsor de l'organisation. Ils se trouvent ou ils se trouvent un mirroir en Belgique de la plage de Jenkins et de l'Olonne. Pour le Mirroir de Jenkins. Depuis quelques mois, ce mirroir a été marqué par un bâtiment de notre Mirroir de Jenkins. C'était le cas la dernière fois qu'on a vérifié mais c'était le mois ou même les années auparavant. La personne nous a contacté et nous a demandé et dit hey, c'est à la date. Donc, nous ne savons pas quand et si on a fait quelque chose d'accord si ils avaient un délai et qu'on fixe je ne sais pas ce qui s'est passé dans le passé. Mais ça s'est passé maintenant. Il s'est réveillé assez régulièrement. Donc, mon propos sur ce sujet est de le mettre sur le Mirroir et le bâtiment ici il n'y aura que ce mirroir le Mirroir de Bell net pour voir si on peut l'enlever et le remettre sur le Mirroir. C'est pour voir si il marche et ça va mettre ce mirroir en retour à l'usage. C'est le seul scope pour ce milestone. Est-ce que c'est OK pour tous les gens? Qu'est-ce qu'il y a? OK. Donc, nous avons un soucis pour être créé pour l'Actobre Festival. C'est pour moi. Il y a quelqu'un volontaire. Non volontaire. Je le prends. Vous pouvez toujours demander des mots. Un mot sur le cloud oracle qu'il y a qui a besoin de nouvelles issues. Marc, je vais vous donner un summary du cloud oracle. Et je vais expliquer le travail. Oui, il y a 18 mois ou deux ans on s'est abonné comme le projet de Jenkins à l'initiel oracle comme ils l'ont créé leur cloud. Et on l'a utilisé pour sauver l'argent. Mais c'était un 12 mois ou un 18 mois limité. Et maintenant on est revenu à payer le prix pour les ressources oracle. Et plutôt que de avoir un plus plus de cloud à l'initiel on pense que la meilleure choice est de arrêter d'utiliser le cloud oracle et d'utiliser d'autres locations. Donc j'ai eu l'intérêt pour savoir comment payer l'initiel oracle du cloud oracle. Il peut être payé par le projet de Jenkins qui peut être donné par un autre company ou autre. On a l'archives d'archives.jankens.io qui est le seul ressource currently en cloud oracle. Toutes les autres ressources sont en train de s'arrêter. Mais cela doit être poursuivie. Si Terraform ou si Cloudflare R2 est un candidat d'archives.jankens.io qui a un web server avec juste déliver un whole bunch de files infréquent. Si pas, nous savons comment faire pour les autres providers AWS, Azure, DigitalOcean, etc. Ce n'est pas un déliver beaucoup de files mais beaucoup de files sont copiées et nous commençons le web server et nous sommes prêts. C'est-ce que vous avez besoin Damien ou est-ce qu'il y a quelque chose que vous voulez parler ? Pour moi, c'est parfait. Pour les autres, c'est expliquer pour vous tout. C'est cool. Donc, j'ai deux issues pour créer pour ce sujet d'archives d'archives et une pour la clean-up de l'autre des projets. Nous avons Terraform Project, States et documentation. Archive Jenkins IO est un web server qui serve deux proposes. C'est un mirrore en partie ou bien, d'arriver Jenkins IO. Et c'est un mirrore qui a l'air comme le nom indique. Archives signifie quelque chose. C'est un on n'a pas un limiter sur ce que l'on le mirrore. Vous avez tout là-bas. Le data sur ce serveur est le même que les bouquettes utilisées par Jenkins IO mirrore redirector pour vérifier le fil de fingerprint pour savoir à quel mirrore il redirect. Théoriquement, nous devons avoir la même data sur les deux. Donc, les proposes que je fais sont au long terme pour ajouter un server STTP ou ajouter un visage sur un service existant STTP sur ce bouquet sur Azure, ce qui signifie qu'il va effectivement bouger nous pouvons bouger le service Azure Jenkins IO sur ce service STTP. Mais cela signifie que nous allons augmenter l'un à l'autre sur Azure sur le long terme. La deuxième idée que je crois que l'HRV a fait le même proposé qu'yesterday lors de la rencontre que nous pouvons utiliser Cloudflare ou un espace digital ou un mirrore pour assurer ceci. Si c'est un espace digital que cela pourrait être puisque nous avons évoqué un espace digital sur le centre de l'updates il est en train de bouger sur Cloudflare. Cela signifie que je serai sur le top du travail que l'HRV a fait autour de l'enjeu. Donc nous pouvons déployer un mirrore sur un espace digital qui va augmenter le cost sur un espace digital mais qui va éviter de risques sur la porte Azure. Donc c'est un peu plus le travail un peu plus lent parce que nous devons synchroniser tout le file une fois de l'archive ou Azure sur le site de l'Océan une fois. Mais ensuite nous avons un mirrore sur le site de l'Océan et le bandwidth pourrait être chargé de là-bas. Je n'ai pas checké l'amount de data qui va sortir de ceci. Je ne sais pas si Rackle est misé sur cela mais cela pourrait être le path de décision que nous pouvons évaluer le costant sur d'autres Clouds. Est-ce que ça rend le sens? Ou est-ce que vous avez d'autres idées ou besoin pour la clarification pour l'archive Jean-Kin-Caio? Ce sont des options très belles. Et dans le futur, on pourrait ajouter les buckets de Cloudflare si besoin. Donc, je vais ajouter des problèmes et nous allons ajouter ces problèmes sur le milestone curieux que c'est le top niveau top priorité de l'opinion parce que nous voulons s'évaluer pour éviter de payer plus. Ok, je n'ai pas d'autres topics donc je crois que nous devons laisser Mark parler de support Java si vous avez de nouvelles issues. Ok, donc Mark, votre tour. All right, so this one is and Damian, if you could open the diagram so that people can see it on screen. This one is it'll be raised as a discussion in the Jenkins developer list and user list proposing a transition from our current way of supporting Java to an eventual 2 plus 2 plus 2 model. Java releases now come out on a consistent clock every two years. Java 17 released in September of 2021. Java 21 releases in September of 2023 and Java 25 is expected to release in September of 2025. This two year clock they've committed to as part of their development processes. So it's in stated in an oracle blog and the open JDK process project and Eclipse Temeran are all working on this to every two years a new major a new LTS Java release is delivered. However, the Jenkins project developers really don't want to support 3 Java releases concurrently. The idea is let's only support 2 concurrently and in order to do that we're proposing this 2 plus 2 plus 2 model for the first two years of the Java release. We will support the Java release but not required. It's not mandatory minimum for the second 2 years of the life of a Java release. We will mandate that is the minimum Java version which Jenkins will support and for the last 2 years of a Java release while the Java vendors are supporting it. Jenkins will no longer support it because we will have moved on to the next. The idea this is not a this is not a commitment. This is not a a yes. Everyone's agreed on this. This is an idea that I'm proposing and will be discussed further. The hope though is that by early October we'll be able to have agreement from people that this is a good model for us to go towards and Basel Crow has agreed to do a blog post announcing Java 21 support announcing end of life of Java 11 in October of 2024 and announcing this transition. So we've got now we're going to do one bigger blog post with all three of those things so that so that it's all captured in one. Any questions, concerns or comments? I believe that as infrastructure it looks like it's OK given the way we were able to release Java 21 and the fact that it's now being led. My proposal is that we in the idea to support that kind of effort whether or not that will be the plan or the plan might be changed for the Jenkins project. My proposal is that we try before end of year ideally to move all our controllers and agent to GDK 21 to support the world effort. Do you think it could be affordable for the team? I like that idea. That's one that I hadn't considered. One of the things Basel noted in governance yesterday is there are activities in the first two years of supporting a Java release that are not really described here. Things like install the pre-release before it's evade before it's available as a release install the release annonce the end of life of the of the preceding release. All those things that we need to do a detailed view of one of these bars and look at what the sequences are and one of the things should be added. I think what you just suggested, Damian that we should put a when does Jenkins info make its transition? I like that. OK. But thank you. That's all that I have. Thanks for that proposer. That makes sense. That's really a leading edge for Jenkins. We haven't had this in years. So I personally I really like that proposal. So yeah, let's challenge ourselves for the infrastructures to support that efforts as much as possible. We might want to start with private controllers or eventually starting with Jenkins on its own, it depends. I propose that we first wait for GDK 21 to be used with its official non-early available release. Then we clean up the remnants of the GDK 19 that we provided early to developer. And once we are there, we can switch on the world GDK 21 for agent and controllers. I like that. I like that cleanup thing because we should not leave the debris around for later cleanup. That's I had not even thought of the Java 19 and Java 20 things that we may need to remove. But you're right, we should get rid of those as part of this process. Remo, GDK 19 remnants. Then focus on GDK 20 for our production controllers. Agents. OK, that's all for me. Do you have other topics to add or is that OK for everyone? OK, so I'm shooting down the recording first. So for people watching the recording, see you next week.