 Hello everyone, this is Jenkins Platform Sieg Meeting. Today we're on the 16th of January, 2024. Today, we have around the table Marc Waite, no Ken Salermo, I'm afraid. No AirVe yet, he will maybe John later on. Kevin Marlins, thanks for being here. And myself, Bruno Verashten. We don't have a very big agenda today. We have, as always, open action items. We'll talk a little bit about Java 21. We'll talk about release work on the agent and control images. And then the work in progress on images, which has been done recently, we'll maybe talk about Jenkins Artifactory Bandwidth Reduction if there is any news. And we'll talk about, briefly, Docker-based Quick Start tutorials. Anything else, Kevin, or Marc, that you would like to add to the agenda? Yeah, actually, so a question about how to handle operating system updates to the, to Jenkins Core. And the example is I just submitted a pull request that was merged for 2.441, but I realized we probably have to do something like that about every six months, just to be sure that we keep that thing fresh enough for our users. So it's a question for us as a SIG, do we want a reminder? Do we want to put it on our agenda every, every so often, et cetera, that kind of question. And it'll wait till the end of the meeting, just fine. Okay, okay, thank you, Marc. So first of all, the usual suspect, pollution Docker container. I don't think there is any news around this. We still have to communicate its deprecation in one way or another. I think I can remember that at the end of last year, I can't remember if it was Damien or Eva or somebody else. It was written in another place, I can't remember where, unfortunately, but we have progressed a little bit about the announcement of the deprecation of the pollution Docker container. Maybe I'm the only one remembering that thing, or maybe I even invented it during my sleep, that's it. No, you don't know about that either, okay. It is not illusionary. It is not, there really is a blue ocean Docker container and we do want to deprecate it, but low priority, the actual use of the thing is not a worry for me right now. So it's, yes, it exists. And yes, I think much more valuable, and I assume we'll get to it when we talk about released work on agent images has been Eve LeMere's work to unify two repositories into one, so. That's why in the introduction, I was hoping that the LV would come later on to talk about his major achievements, which has been merged last week or this week, I mean, but we'll talk about that later on, hopefully with LV, we'll see. Then Kevin, there was something on you, you were supposed to check for Python in all point direction in the tutorials, but the tutorials as it is now is kind of deprecated or not so good to follow. So I don't know if you even took some time to review that or if you're waiting for the new version of the Python tutorial to appear. Yeah, so Mark and I actually took a look at this. We went through the documentation for Jenkins.io to find the specific interaction between Python and Alpine this is referring to and didn't find any instances where it was interacting exactly the way it was laid out and didn't find any instances even in the tutorial where it was providing that exact instruction. So nothing to change or update in terms of the documentation for that, thankfully. It seems like it was pretty much what that, or I can't speak to the interaction that Damian was worried about in fixing, but yeah, we didn't see anything that we needed to flag or changing docs. That's a good thing. And earlier today, I retried my draft pull request about the Python tutorial. And I was wondering because I just didn't remember beforehand when we talked about that two weeks ago, if there was anything to do to change in the existing tutorial regarding the latest versions of Python, the need to have a virtual environment and so on. So I couldn't remember if it was in the sample app or in the tutorial or in the Docker image within the QuickStart tutorial repository. But I find out today. So now I know it's just in the Docker image, so that won't need any effort from the newcomer, the end user, whatever. It's deep inside the Docker images which is in the QuickStart tutorial. So we're all good to go. We don't need that. Any comment or question about that subject? No, okay, thank you. Now Java 21 support, two plus two plus two Java support plan. I had a look earlier today and your Jenkins enhancement proposal hasn't moved a lot lately more. Hasn't moved at all. And I've got lots to do on it. There's been no progress and shamefully no progress for a month or more. But it's all on you, I guess, although we still have to discuss with the rest of the community. Well, what we need is, there's lots of discussion needed with the rest of the community, but I'm the catalyst for that. We will probably discuss some of it at the Jenkins contributor summit in foster. Because the challenge is, we need to describe the steps to take to stop supporting a Java version, which is what will happen October 2024. And we need to describe the more recent steps that we took to add a new Java version, which we did with Java 21. So each of those needs more detail and will help. Yeah, got it. Thank you, Mark. I know there are still some stale PRs waiting to be reviewed or merged. I think in my, I had a table somewhere, a sheet where I wrote, we wrote down all the 250 plugins that were to be updated with Java 21. I think a few of them are still in the right white color. So they are not green. So they haven't been merged. But I don't know if there are, if they will be merged one of these days. I know you pinged, you knocked on the door or quite a few plugin maintainers recently. And this has proved useful and successful because I, so I think three merge requests, pull request merged last week or so. So it's still working, but I get there are also other repos that won't get merged until whenever they get merged. Right, so it highlights that the technique has worked. What I did was I looked at the plugin, looked at the plugin GitHub repository, looked up the specific maintainers of that plugin in the repository permissions updater, and then mentioned them with an at mention in the comment, hey, would you be willing to do this? Because sometimes these maintainers have turned off notifications of pull requests for their repositories because they have so many, whereas they typically have not turned off notifications if they are explicitly mentioned. So as an example, I've still got on the Java 21 pull requests that I submitted, I've still got three open, three, there are three pull requests that I have open that I've sent reminders, I've done the various things and nope, no progress. So it's going to happen. Some subset of them won't be merged. I haven't attempted to find out how many of your pull requests haven't been processed yet Bruno, you can easily see it from the github.com polls page. Oh really, okay. Let's go. You want mine? No, that'd be great, yeah. So if you go to github.com slash polls, you'll have to be logged in as you, but hopefully if you're already logged in, what we'll see is the list, the status of your pull requests. Okay, so is open HPR author Gunther, yes, good. Archived false, yeah, great. And can I filter for Jenkins CI and plug in maybe? You could or in this case, I would think you just want to filter for Java. Just put the word Java or JPK, right? So here we've got post build script, parameterized scheduler extensible. So it looks like you've got keep scrolling downward. Maybe you've got 10 or 20. Wow. Okay, quite a lot. Well, but here again, this may argue for the, and several of those I sent, several of those I've done reminders on. I don't know that I've done reminders on all of them, but actually any one of them that has a red X by it, if you want to just ping me separately, I can make sure that it gets to replay the, exactly that it replays. Yeah, that would be cool. Okay, let me write that down before I forget. A few still waiting. A few, many. And many is okay. Okay, don't be modest. Yeah, many are still waiting, awaiting merge because we've not received, because the plug-in maintainer hasn't merged them. Yep. Technique, that's even a word in English. And we'll get in touch with Mark to replay the failed pipeline. Yeah, sorry about that, but it's just, it's easy to do if we just know the list, but I can't generate the list of your pull requests directly myself as far as I can tell. Yeah, I'm gonna play with that. Thanks a lot for proposing Mark, that will help making the thing progressing, whatever. Oh, wait a sec, maybe I can. Oh, really? Yeah, because it's got a clear author colon thing, and yes, I can, I don't need you to give me any list. I got it. So how did you do that? Well, in that on the github.com page. Okay, there is, okay. Up at the top, there's a select condition which says author colon you, I change it, when I do it, it comes up author colon me, I changed it to author colon you, and it just satisfied it works so I can see it. That's great, nice. Thank you Mark. Now, for the release work on agent and control images, this has restarted, because there was a pose at the end of last year. So as for the controller, we only had one version. Oh, maybe two now, because I guess during, just before this meeting, this has been revealed. So maybe we have the 244, oh, no, not yet. Maybe with the tags. Yeah, so yeah, it's a manual operation and somebody has to do that. Mark, you told me that two weeks ago. So the tag is this, but the release is not yet available. Oh, wait, hold on, hold on, which release, so. 2441. It definitely is released. Oh, on the Docker container, you're right, I missed it again. Thank you for inviting, because the Jenkins core release is correctly recorded. But the release on the Docker container, on the Docker repository is not. I'll get that done. Thank you for reminding. Thank you for doing that, Mark. So of course, the 244 didn't see much change except move to the weekly 244.0, but there was one work in progress that got merged, which is the improved logging for common failure when using default config. I don't know if this person is a first time contributor, but he found the problem regarding the right permission on the repo when starting the Docker image. And he decided to make a pull request to solve that. There was quite a lot of discussion, but finally it made it into the main branch and has been merged. So thanks a lot, Clinton Steiner for this work that will definitely help new covers when it comes to Jenkins. And there was another thing despite just changing the weekly version, it's only run GitHub action from Jenkins CR repository. So that won't change the life of end users, but for developers, maintainers, contributors, that will help because we were getting quite a lot of emails saying, oh, this GitHub action doesn't work on your fork. I know I can do anything about that. But now we won't get, hopefully we won't get this kind of emails anymore, right? Yeah. And it's, you know, when there is an annoying noise, sometimes it's annoying, it's annoying. And then after a while you even don't realize that the noise has gone. And I think that would be the same for the emails. They were kind of annoying. And now that they're gone, I almost forgot about them. That's okay. I think it was a work or a proposal from, not my fault, Alexander Bondes, if I'm not mistaken. And that's a good thing. I think you will appreciate that also, Marc. It will decrease slightly the number of emails you get per day. Now for Docker agent, we had a few version dumps and of course a big merge from Herve that led to four new releases. So we had the Jenkins Remoting version of God that got upgraded. We bumped our client next to the newest version from 2024. We upgraded a bit CLI 22520, that won't change anything for the end user that just for the update of the repo. But the most interesting to me is that the work from Herve wanted to build both agent and inbound agent in the same repo because of the pain in the neck, frankly, to keep everything up to date. It's not beautiful. So now it works after more than one month. It has made it into a release of the last release. Thanks a lot, Herve, for the great work. We have been talking about that for months, frankly. So I'm super happy that this is finally happening. And there are next steps, some more important than others, all of them are listed there. The first one that Herve talked about in Gitter today was let's find a new name for the repo. And I haven't been able to find a nice one. So if you ever have an ID, it's in Gitter in the channel Docker, Jenkins Docker. So feel free to share your ideas there. It will make Herve happy. And us too. Any common question about this one? Okay, thank you. Now for inbound agent, which is bound to disappear, I'm afraid. There were a few version bumps that led to three new releases. So of course we bumped the parent Jenkins agent version. We also got update CLI. And I think that Herve will build, I don't know how to call that, empty or blank, white, whatever release. That is the same version of the agent and the input agents, but within the new repo. So I don't know if any of you know more about that. I would have loved to have Herve's insight about that. But yeah, we'll, yes, Mark, no. I think his plan is to do a tombstone release. That's what I was looking for. Thanks a lot. Right. And then continue. As far as he and I discussed it earlier today and it's, it looks like it's going very, very well. The, the combination previously we had three repositories that we're worrying about how to create a Jenkins agent. We're now down to two with inbound and agent combined together. Very nice. Yep. Thank you, Mark. And now for each agent, nothing groundbreaking. It's just the update of DBM and bookworm to the latest version, not the latest version, by the way. 2023-12th ageing. So I'm sure there was another one because I merged quite a few pull requests today about that. So I guess it will make its way into the next release of SSH agent. There is nothing really changing, nothing important for us really changing in the latest versions of bookworm. So the work in progress on images has shrink down because LV got his PR merged and the PR we talked about earlier, which was about getting a better logging for common failure has also been merged. So we still have on the work in progress, the use Docker compose to publish images that relates to Windows because we used to work with something called PS1 or PowerShell, I guess a script. And now thanks to the work of LV, we are targeting the use of Docker compose instead of this cryptic, at least to me, PowerShell script. And then LV again, Contrater, Adapt, Update, TLI, JDK, 11 and 17 to Windows because for the time being, it's not yet handled for Windows or badly handled. I just can't remember. Mark, is there any news regarding the Jenkins Artifactory boundaries or how we satisfied with the way it worked until now? As far as I can tell, we are satisfied with how it's worked. We've successfully reduced the bandwidth requirements and seen that the bandwidth usage went down based on log file analysis. And, and we did some final configuration tuning to remove some debris from a repository we affectionately call the Orphan's Repository. So the Orphan's Repository is a place where we had put binaries that were not available from any other location, except from things that were cloning the entirety of of the Apache Maven Central. We don't want to present to the public Internet a copy of Apache Maven Central. That's a really bad thing to do. It increases our bandwidth use dramatically. Therefore, we've got this, these relatively few files that we keep there. The one that's the most noteworthy is called JB Crypt. It's a 2015 implementation of the OpenBSD crypto library in Java. And thankfully, a user submitted a pull request to switch from that 2015 version to a 2021 version that is the exact same Java source code just delivered by somebody into a public location. So that's not Apache Maven Central. Yeah. So we're very pleased. Nice. Thank you, Mark. Now, Docker base quick start tutorials. So it's a thing in several steps. We have a new repo in Jenkins doc. Hey, aiming to help with existing tutorials regarding Maven, Python, multi branch pipeline and so on. We have a revamp on the Jenkins site, your website of these tutorials using this repo. I just cited. And the Maven one has been merged today. If I'm not mistaken, Kevin, that's right. That's correct. Maven's already merged and yeah, it should be appearing today later if it's not already. That's super cool. Thanks a lot for taking the time Mark and Kevin to review. Thanks also to Alexander Bandes for reviewing this PR. It's far from perfect, but it's much better than their previous documentation, the previous tutorial. So I'm really happy with that. I switched the Python one from draft to reviewable today. It's maybe on a lower quality than the Maven one, my fault. I should maybe spend a little more time on polishing that tutorial. We'll see where these goes. I retried today the Python tutorial, as I said, maybe in the beginning of the meeting and it worked for me. The main differences are in the Docker file because we have to create a virtual environment. It's a requirement for the from book wrong up to. Yeah, in the future, we will have to do that and it's cleaner and it's not using Python too. I also saw somebody today country member if it was on Gitter or on Community Jenkins IO saying that it was on Github because there is an issue on the tutorial, the sample tutorial on Python. Somebody created an issue saying that doesn't work anymore. It's failing on the test part on the test stage. So I just referred them to the preview of the new version of the Python tutorial and hopefully that will work for them. At least it works for me. So whenever you have time, feel free to try that new tutorial and point the issues you're having or maybe it will work. Never know. It works for me. With Docker, we're supposed to get rid of that. It works on my machine. It's supposed to work just about everywhere. We'll see that. Fingers crossed. Any common question about that before we go to the next subject? No, no questions. Hardy, congratulations. Major victory. The Maven tutorial being done is the first of multiple steps. My hope is we eventually get to the point where the awful, ugly, horrible instructions in our Docker install guide are replaced with a very simple. This repository Docker compose up. I would love to. It will take some time that I would love to participate in that. And once again, thanks a lot to Ashutosh Saxena for working last summer with us in order to make this possible to Jean Marc Messon and to West for grotes his name. You know who you are. The other commenter. Sorry about that. And of course to Google for making this possible. That was a great thing. We see now why this is a success and it's really good to see. Thanks, Mark. So Mark, you wanted to tell us about operating system updates to Jenkins core. Would you like to elaborate in that? Yes. So maybe maybe let's open, let's open the poll request and talk about why it happened. So github.com slash Jenkins CI slash Jenkins. Or even better. No, no, even better, even better. Go to Jenkins.io and the download page. We're going to use the change log. Because Kevin's merged the change log. So click the download button on the weekly side, regular releases, change log. Okay. Update operating system, end of life data for Amazon Linux, Alpine Linux. Yes. So click that poll request link. Yeah, I saw that one. Okay. So what this was is and Daniel Beck asked the question. He said, Mark, whatever mode do they do this? We're going to have to maintain it forever. Right. We're going to have to update this and he's right in the sense that we need to, if, if we want to tell people that their operating system is becoming and reaching end of life, we have to have an updated list somewhere that says when your operating system reaches its end of life. So Daniel's comment is exactly correct. He's right. This requires updates. So, so what, what the question was is what led me to discover it and you can ignore the specific details. I actually wanted the screenshot. So back to the. Yes. Sorry, but I just, I didn't think it was that's not completed, but that's it's okay. Oh, and, and it's not some of that some of that was polishing. So some, some of the differences you saw there are pure polish and admittedly Amazon Linux created has a, has a complication that this particular code had never seen before. One operating system is a sub pure substring of another operating system. And it was doing, doing things that made that not, not happy. So, but the, the crucial, the crucial things that led to this. First, someone asked a question on community dot Jenkins.io. Why doesn't. Except new work with the get client plug in. It fails with this message that except new is not implemented. Except new is a feature of modern SSH versions, but sento seven red hat enterprise Linux seven and its derivatives do not deliver a modern SSH. They deliver SSH seven dot four. Whereas nine dot something is the current release. So the, the open SSH people regularly release new versions roughly quarterly and seven dot four is a long time ago. So while researching that, I realized, oh, I'd never told people that Amazon Linux two is in fact a red hat derivative, but it is. It very clearly. I didn't know that seven. Me neither. But looking at it, it is clearly a, and they say so in their documentation that it's a red hat seven derivative. So, so the answer is ashamed of. Okay. And their users and their users like it like many red hat seven users. They like that it's very stable, very, very stable. So, so the, the catalyst was red hat enterprise Linux seven is dead, but this never told the user of Amazon Linux two that it was dead. And, and therefore that was a gap. So I wanted to add Amazon Linux two while I was adding Amazon Linux two, I looked at the list and realized, oh, I forgot to add Alpine Linux three dot 19 when it released. I forgot to add Amazon Linux 2023 and I'd forgotten to add Fedora 39. It's like, oh, there were a lot of forgots in this, in this story. So, so the idea was, okay, let's fix some of those forgots and, and then, then looking it was, oh, and by the way, there's test data that's missing that wasn't covering all the things that it was saying it was. Those are all added, but the question for us as a group is how do we deal with this for ourselves because I think it's a platform sig thing, right to do this. Should we put a reminder for ourselves every six months that says revisit this list or every three months or whatever. Yeah, I get it. In fact, I don't know if that translates in anything in any way, but it looks for me like the CZ CZ CZ fifths, you know, the guy who gets his stomach eaten each and every day and then it grows back and the next day it's again. I was not expecting a reference to Greek mythology and the guy or no, no, is that is that is that from Dante's Inferno. So Sisyphus is the guy who pushes the stone up the hill and then it rolls back. I got it wrong, but it's the same kind of pain. Right, right. So I understood. Yes, this is that this is a task that needs to be repeated. And yes, rolling stones uphill might be considered a metaphor for that, right? Yeah, but the thing is, we have to know when to do that and we maybe have to find another way or a more pleasant way to do that because it doesn't look like fun. Of course you did some polishing cleaning and so on, but 14 files changed for four new data. That seems like a lot of changes. Doesn't provide fun. I don't know what is your process, your workflow, whatever, but wow. Well, and actually the reason for the 14 files was because of the gaps in test data, right? That was because the original implementation was flawed. So the large number of files here in terms of actual number of files that will happen in the future, it will probably correspond much more to one file for Amazon Linux three to three dot 20 of one file for Fedora 40, those kind of things. So relatively smaller. This one happened to be large because I discovered a bunch of mistakes. But it's not as simple as declaring something new in a JSON XML or actually it is almost almost that simple. Okay. So, but it's I'm confident it's something that you would be comfortable doing having. I wasn't expecting that. Look at my pattern that I used. Something that I can do something I think most anybody could do. We could probably even automate it because end of life, end of life date, the end of life dot date website has a REST API that they provide this data. So that's where we could we could automate this if we wanted it just feels like a lot of work to automate something that's only going to be touched every six years or 12 years. I don't know if we should go up to the complete information but I was wondering if we couldn't get, you know, not a dummy output regret that wouldn't do anything except alert us that there is a new data to import into that not doing the whole work and create the code and so on but just put a question and you know they're all in the mail or something. Let's say there is something new. An operating system just got end of life something like that so that we know that we have to do something. Yes. I was thinking of course of automation having something to calendar is okay because the process could fail. But I'd like to have a look at how to. How to automate that in a way or another. What do you think of that Kevin. I mean, yes, ideally automating it would be the way to go. That way it saves everyone the trouble and concern later on down the line. But if it's as easy as it seems I mean I'd even be okay helping in whatever way. The seem like it doesn't seem very far off from like what the update CLI ultimately does so. Yeah. Cool. So. Mark we could always add something in the Jenkins calendar for us to prepare before that kind of meeting, you know, maybe on a Monday or whatever so that on the next Tuesday we know if there is something to discuss that a new. An old operating system reaching end of life. And then maybe I should try to automate something and see where this goes if you're not against it. Yeah, I think I actually am against it just because I don't I think there are other things I'd rather have you automate much more than this documentation things and other other places that are much more. This for me is is an every six months or every 12 months little side trip. So I don't think it's worth with us and there we'll do them. Well, and even I'm even fine if we just put it on our agenda and agenda and remind ourselves every so often. Yeah. The Jenkins calendar would be fine as well because the infrastructure team certainly uses the Jenkins calendar for their reminders. Yeah. Cool. Thank you Mark. Thank you Kevin. Anything else you'd like to discuss about. No. Okay. So let's wrap it up. Thanks a lot for being here. The recording should be available from 24 to 48 hours. Hopefully. And I would say I'll see you in 15 days two weeks from now, but I don't know if we'll be back from for them. When we should we should be. Oh, we won't be gone yet. Right. So and I don't I don't fly out until. The first right and I think Kevin flies the first as well. So I think we'll be here in two weeks. Oh, cool. Thanks. So see you two weeks from now. Thanks a lot. Bye. Bye. Bye.