 Hello, everyone, this is Jackman's platform, SIG Meeting. Today we're on the 12th of March, 2024. And around the table, I would say face-to-face with just the two of us, Mark, Wade, and myself, Bruno Verashten. As always, we have a few, just one, open action items. We'll talk just a little bit, because I don't think much progress to see there about Java 21. We'll talk about the ways to work on agent and controller images, the work in progress on the images, and a little bit about Docker base quick start tutorials. And if time permits, we'll see a few words about risk 5. So as always, go ahead, Mark. One more item for the agenda, an announcement about the ampere server and running its first jobs. No way. Oh, so cool. Bang. Wow. Oh, you have to. Yeah, OK. So put it in there. We want a topic. Yes. No, that's a topic I want to talk about first. But no. First is fine. We can talk about it wherever you want. I just want to be sure it's on the agenda. No, I just wait. I'm just a kid in a candy store. I want the biggest sweets. Whatever. So as for Bluish and Docker container, I know we still have to communicate more about its deprecation. I think it was last week or the week before. We had on communityjenskin.io a user complaining about the actual Docker container not up to date with the latest versions of everything. Of course, it's deprecated. And I told this user maybe you should do the other way around. You know, start with a fresh Docker agent or Docker usage agent and then add the Bluish and plugin to get it to work. But, well, that didn't end the right way. And it was pretty pissed off. But that kind of things happened. It is deprecated. And we should let the end users know it's not such a good idea to keep using that. Well, and that user showed an anti-pattern, right? The anti-pattern was, ooh, I'll upgrade the Jenkins war file inside the container image. And that's actually absolutely upside down. You want to use a new container image as you're from. Yeah. Yeah. I think it was kind of desperate to get things up to date. And he thought that maybe that was the only way to do it. But no, not such a good idea either. So I don't know if you have any better idea than starting from a fresh Docker agent image and then install the plugin. That's what I do. OK, and even better, switch to the new pipeline, grab you if you can. Well, Mark, I haven't seen any news on the Java 21 support, the 2 plus 2 plus 2 Java support plan. But that was expected. There are lots of discussion to be had, right? Right. Although, OK, there is a piece of news here that's worth highlighting that I have some responsibility for. Maybe not in here, but in the meeting notes. It's not inside this. But I saw while I was on vacation, there was a recent Twitter announcement from the Spring project. So the people who do Spring Boot and Spring Security framework, the Spring project has announced the end of life of Spring Boot 5.3 of Spring 5.3. That's just called Spring 5.3. And Spring Security 5.8 in August of 2024. And the reason that matters to us is I believe, I've got to check with the experts, but I believe Jenkins uses Spring Security 5.8. And so we'll need to switch to the new version of Spring Security, but I think Spring Security 6.1 or 6.2 requires Java 17. And therefore, we can't really make that change until the October or November end of life of Java 11. So it's a complication that needs to be discussed. It may be that we ask the Spring Security people, it may be that we accept things and say, fine, we'll run with an officially end of life Spring Security between August and November. Or we ask the Spring Security project, would you for the benefit of the Jenkins project please be willing to answer our questions until we drop it off end of life? I've got to have some discussions there and probably the Jenkins developer mailing list. And let me see if I can find the tweet and put a link to their blog post because their blog post was wonderfully clear. They did a really good job of describing, look, we've given Spring 5.3 this very long life and unusually long life, it's time now for us to switch off and we're going to Java 17. I was wondering because I know I have read this tweet and maybe even the article, did you retweet that? I did, yes. Oh, that's why, I was wondering, how did I read that? Because I even didn't know Jenkins was using the Spring Security 5.8. So that's thanks to you. Thank you. Well, and the fact of Spring, we don't actually use Spring Boot as far as I understand just the Spring Security framework. But that's already an important thing and the mention of 5.8, which I think is the Spring Security version that matters to us, was sort of a brief mention in one sentence in the announcement. So it's not immediately obvious from the title that this would affect Jenkins, but I think it will. So I'll put a hyperlink to that into the document, into the notes here. Thank you, Mark. Thanks a lot. Anything else regarding Java 21 or the 2.2++2? Well, so we've certainly still got to capture what we learned from the Jenkins contributor summit for 2++2++2. And we've made progress that Basel Crow and Vincent Latombe have both done improvements. Actually, it should be the other direction. Vincent started it. So Vincent Latombe was the one who started the implementation of improvements that help with the transition from 11 to 17. There's still more to do, but it's really great that they've started that. Oh, and you found the link. I did, yeah. So now I've got to double check that I'm not mistaken in terms of the version of Spring Security framework that we use in Jenkins Core. I'll go check that now. Yeah, we don't. Yes, we have Spring Security Bomb 5.8.10 that is included. And so we've got to think more about what does it mean during that August to November or August to end of October time. Actually, it's just August to end of October time while Spring Security no longer supports 5.8 for open source or for publicly, but they're willing to do it for commercial. And so they might be willing to extend life for us briefly. Yeah, fingers crossed. I know that the, which project is it? Jetty Project has done that for us where they've accepted that, hey, we're a little bit of a special case and they've extended life just a little. We don't want to create a burden on them, but on the other side, we're grateful consumers of their work. No, no, I'm wrong. Spring Framework Bomb is 5.8. Oh, no, Spring Security Bomb is 5.8. And we have the Spring Framework Bomb 5.3. So both of them are in our list. Okay, good. Well, that's good to know. So some more work on the Jenkins Project community plate. Well, yeah, actually, could you make a note here? This is, I should have done this research before the meeting, but let's put it in. It's not just Spring Security. So under the headline that's talks about, under the item that says end of life for Spring Security 5.3, note that Jenkins uses the five, currently uses 5.3.32, 5.3.32. And so we'll... Oh, okay, yep. Yes, 5.3.32. At least the bomb is included in our bill of materials. So 32, not 22. And so that means we've really got multiple components that during this August to October timeframe, we need to decide what do we do with them. I don't think we can or should accelerate the end of life of Java 11 for the Jenkins Project. We've said October, we hold to October, but during this period, we'll be off the edge for Spring Framework and Spring Security. Thanks a lot. That was kind of unexpected from me, but that's really interesting. And yeah, we have to keep on moving on the versions of Java. There is no other choice. And that's a good thing. Now onto the release work on agent and control images. Of course we had the two weeklies of 4.48 and 4.49, nothing special in the 4.48. The only thing I noted in the 4.49 is that there is something linked to a platform. I mean, there were two PRs one, which addresses the need to not attempt a restart on the operating system where it's not supported. I guess it's macOS or all that. I don't know, I haven't looked at that. I didn't know if that was just about a macOS or if there are other target OS. Well, so this, the OS that's specifically referenced here is a tandem nonstop. And tandem nonstop is a Linux variant. It's actually a Unix variant, but it's designed for high availability. Think of it as a competitor to, who are the other people who do major fault tolerant work? It's a fault tolerant operating system, intended to be the kind of operating system where you pull a processor out and it keeps running. That kind of thing. You just drives out and it just ignores you when keeps running that kind of level of fault tolerance and tandem nonstop. And in this case, it is a Linux variant, but does not have one of the libraries that we need. And so what Basel implemented is, hey, detect that that library is not there and don't attempt to do the steps that would use that library if the library is not there. Okay, it can be the Lipsy. It is GNU Lipsy, yeah. It is. Oh, oh, sorry. If I look excited, that's because I have the same kind of problem on another operating system that is not supported, where as I don't have a Lipsy, every time I restart after updating plugins, for example, it just say, no, I can't find Lipsy. I can't restart and I have to kill Java all by myself and it's a manual process and it's a pain in the neck. Yes, it's Android. And so this will fix that. This should... Oh, that's great. You're a very good test case. This should fix that. So if you'll try 2.449, you should see that it will behave much better. I run the weekly. So yeah, oh, that's super news. Ah, I love this. Now there was another piece of news on 2.449. Oh, that's the latest, sorry. That is unrelated to containers. So actually, and it's unrelated to the changelog, it is that while the 2.449 build was being run, one of our mirror providers is offline doing an operating system upgrade. Yes, they're upgrading from CentOS 7 to something newer that supported. We're delighted that they're doing that upgrade. That's exactly the right upgrade, right? Good choice. But then because of the complexities of that upgrade for them, they're needing three days to do the upgrade. So Monday, Tuesday and Wednesday of this week, they're down. However, we have multiple mirrors. Therefore, it's not a catastrophe that one of the mirrors is down. Right now, the 2.449 release is only mirrored on four of our seven or eight mirrors. So, but it is at least mirrored on four. So it's mirrored in China. It's mirrored on one machine in the United States and on two machines in Europe. So we've got reasonable coverage even with this mirror being down, at two machines in Europe. Oh, yeah, yeah, yeah. I don't know why. So it's Belnet and University of Aachen. Oh, so neighbors. Exactly. In Aachen just next to the Belgian border. Correct, right. Cool. Mirror, let's be clear. Okay. But that's a good thing. They're all living sent to a seven. Right, right. That is, there is no complaints from anyone. They provide great service. They donate that mirroring service to us as the Oregon State University open source lab. They donate those services to us. They've donated them to us for years. We've been such a happy consumer of their work and I'm delighted that they're doing the upgrade. That's really great. Next week, they will upgrade another one of their servers that we use. It will probably be a lower impact or maybe it's later this week. It'll be a lower impact than this one because this is a specific one we mentioned by name. And I think I saw a new mirror. I don't know if it's already running or not in Romania. Yeah, there's potential for two more mirrors in Romania and we would love to have them. Yeah. Thanks, Mark. Now for the Docker agent, just a few version bumps that led to one new release. So we had two version bumps on Windows with Git LFS and Git and on Debian with the latest version of Bookworm. And I think it's a work you started with Kenneth Faleno or maybe he did it all by himself. It was just on the controller that the two of you work together. It's a removal of PPC64 Preview images for JDK 21 and real standard official JDK 21 images instead. Correct. And now I'm not sure that the agent images have finished their transition off of preview images. PPC64 is done, but I think there are still maybe others that are delivering preview images that that work still remaining. I think for ARM v7, that's for sure because there are no official version for ARM 7 v7. But for the other ones, I just can't remember the list, but yes, not all of them have finished migrating to the official images. Right. Now for the work in progress on images, we still have the long running update CLI, JDK 11 and 17 manifest for Windows. It's a draft for, it has been a draft for quite a long time, but it's not an urgent work. So that's pretty cool. Thank you, AirV for the work. Now for Docker agent, we have two PRs which are related in review now, because update CLI changes, change some things here and there. And lately it has made mandatory to add the architecture because a long time ago, a few versions ago, I would say, you would just have to add ARM v7 or AMD64 and then it would do its magic and find the right Docker image. Now you have to write Linux, AMD64, or Windows, AMD64, or Linux slash ARM v7. So a few of our manifest are not up to date with the latest versions of update CLI. That's why the latest versions of the JDK aren't up to date anymore on the Docker agent project. That's unfortunate, but we are working on it. So we have two different PRs. The first one is pretty straightforward. It's just adding architecture. So adding Linux in front of ARM v7, for example, or adding Windows where it's a Windows image so that it works again. And the other one is more tricky. It's also about changing the script file that we're using to detect the exact version of the tamering image. And yeah, sometimes you have a plus, sometimes you have a minus, sometimes you have an end of score. It's kind of difficult. And the problem we are facing these days is because there are some minor, some patch versions of the tamering binaries. And some of them are only targeting macOS. So of course, there is no Docker image for macOS. So the GitHub says, oh, I've got a new version. And then we're looking for a new version on Docker Hub and we can't find it. So this latest PR tries to help with that. As for Docker Assisted Agents, we have also two PRs on the same subject, which are in review now. It's about Windows, if I'm not mistaken. Yeah, it's a bump of Git LFS. And I saw you react on one of these, Mark, if I'm not mistaken. Yeah. Because we had another previous version. I think it was, I can't remember, whatever. In fact, it's a bump Git LFS 14341 and 14351. And I think that the two of them needs the same fix because they don't build for the time being. Well, and Erwe had provided that fix in us in another poll request. So, but I think right now, his time is better spent in other places. So it may be a while before those things are updated. And nobody asked for that update except Dependabot or DCI. So that's okay. We don't have any CV or whatever to do. So we can go ahead and do it when times permit. Now, Docker base quick start tutorial. So the Node.js tutorial is done. It's live. And now we're working on the multi branch pipeline tutorial. Thanks for approving my PR, by the way, so that the sample repo corresponds to the actual documentation. It's almost ready to go. I still have a few screenshots to adapt. And that should be okay. And then we'll tackle with the main Jenkins installation thanks to Docker documentation. Yeah, we'll see. And just in case I also started the code, not the tutorial, just the code for an Android version, just in case we would have the time to write, get started with Android and Jenkins. And same for Golang this week, I started to have a Docker file specified for Golang. I made my first test and it seems to work. I'm not fluent in Golang at all. Maybe one day, one day, we'll see. Mark, next subject, umpire server run its third job. I didn't expect that before the end of March. So how did you do that? Yeah, so well, actually, are you okay stopping sharing your screen? Yes, of course. Let me share mine because I wanna show my screen. I think this is a fun one, just to show where we're at. Let me find the button. Oh, yeah, of course, stop share. Go ahead, Mark, thank you. Okay, so here's what I've got on my system. Let's see, can you see it? Yeah. Okay, so what this is is I took the machine as shipped. Thankfully, they included an operating system on an internal drive. It happens to be CentOS 8, an operating system I have no experience with. So CentOS 8 stream and that's fine. Whatever operating system they chose is great, but notice the labels, Art64, CentOS, good. CentOS 8, good. Now, if we look at the build history, we see all sorts of jobs that have run on this machine. And these are just the freestyle projects, not the pipeline projects because pipeline projects don't show up in this view at all. And so this set already. So for instance, the Git plugin, the Git client plugin built one of its jobs on it. And if we were to look at the console output, we'd see, oh, hey, here it's using this ampere machine and it worked just great. So yes, Arm64 worked great. It did a bunch of downloads, ran all its tests, passed, reported the results, just fine. Yeah, it's boring to use a term coined by John Masters. It just works, it's boring, it works. Exactly, and that is precisely what we want, right? That is a marvelous story. Deepest thanks to ampere for letting us borrow this computer. It's a great piece of work. There's certainly still much more to do to find the most effective way to use it for the Jenkins project because the infra team may want to use it for various things, but right now it's definitely doing useful work for the Jenkins project on my behalf. Right now it's testing Jenkins 2.440.2 release candidate. So the release candidate for next week's long-term support release is being used. That's cool. It's an agent, but it's also a controller. No, no, I haven't run a controller on it yet. So this is just the agent. But the agent that's being executed is from 2.440.2 release candidate. I can see labels like high mem, high rhyming. Is it something that you added yourself or just detect? Oh, okay. So some of these are automatically detected by the platform label or like this one, right? The architecture and the, well, actually here, let's let go, you can see which ones are, here are the labels that I declared. Okay. It has Git 227 on it, it's got a lot of memory and it runs very, very well. Now it's only got 32 gig of memory, but in my environment, that's a lot. But it's got 160 cores, go ahead. How many cores? 160. Yeah, so it's a very, very nice contribution that Ampere has given, has let the Jenkins project borrow this computer and put it to work. And it's a very nice piece of work, really grateful to them. That's all that I had to show. Anything else you wanted to see on it? No, I just also, I high ram, but I didn't see that label written by yourself. So is it also something you added by yourself? Yeah, so if you look here, here's the high ram, oh, high, no, high mem, high mem is, high ram is implied by high mem because I have this thing called the label implications plugin installed, which says, if you have label X, it will use that as label Y. That's good. So this one is derived from, from the existence of this label. That's super cool. Thanks for sharing that, Marc. And definitely this machine deserves more ram. Well, it's great what it's got, but and I haven't figured out how to open the case. That's been a complication, is getting inside the box has been a little more difficult than I expected. I need somebody to teach me how to open the box. Yeah, I won't be that one because I have opened quite a lot of servers, but when they were already discarded. So I know how to open them with a pry bar, but that's a good idea. Right, and that's not the way we want to treat a borrowed server. So absolutely, it's still the property of ampere. They own it. And so I want to be sure I return to them in good condition. Using a cutting torch is probably not the right choice. So am I sharing my screen? You are, I can see it just great. That's cool. Yeah, nothing much to do at Conrad. That's amazing. I love that. And speaking of machines, I have all lay machines compared to that, but nonetheless, we do love when some hardware vendors or other companies want to sponsor Jenkins by lending them or giving them some machine that could be helpful for the project. For example, I haven't opened the box yet, but I have received a RISC-5 board from Tiel Lim. I think he's a pine 64 CEO that we met during FOSDEM at the Jenkins booth. And he also sent two ARM 64 boards, but they just don't compare to your own pairs ever. So they just forget about them. But yeah, a RISC-5 board, why not? It's still early because the ecosystem is not that mature, I would say, but that's, at least to me, that's interesting for the future of Jenkins. And we are also in the very last step in the process to get the Mil-5 pioneer box. I will put the link later on. It's also RISC-5 machine. We talked about that maybe two or three meetings ago. I think it's a 64 cores RISC-5 machine. So that would help us with our first experiments with Jenkins and the RISC-5 because for the timing, we've been trying machines with one core. It's slow, of course. And the machine from pine 64, I think it's a six or eight cores, but yes, 64 will be much better. We'll see. Anything else you would like to share, Mark? Nothing else for me. Okay, thank you. The video should be available from 24 to 48 hours. And we'll see each other's two weeks from now. And until then, have fun with Jenkins. Thanks a lot. Bye-bye.