 Welcome, everyone, this is the Jenkins Platform SIG meeting, March 26, 2024. Around the table today, we have Mark Wait and Kevin Martin. Hello, folks. On the agenda today, quite a packed up agenda. We have the usual suspect, the open action item, Java 21 support 2 plus 2 plus 2 plan and so on. The release work of the agent and controller images, the work in progress on images, and a few words about Docker base quick start tutorials and exotic architectures. Mark, Kevin, is there anything else you'd like to add to the agenda? Nothing, so you've got the topics I want to discuss. Oh, cool. Thank you, Mark. So let's get started with open action items. As always, we still have to find new ways to announce the blue ocean Docker container is not updated anymore. So yeah, it's deprecated, but it's low priority. We don't see that many messages asking for updates on the various media channels. So that's okay. I think people tend to get it or are accepting the fact that it's not updated right now. Now on to the Java 21 support the 2 plus 2 plus 2 Java support plan. I haven't seen new things in the discussion, Mark, but that doesn't mean it's not progressing in any way, right? So Basel and I were just just discussing a day or two ago before the weekend, and we've, we've got more implementations that have happened. We have some more work that needs to be done. And yeah, it's still got more to do. We may ultimately take Basel up on his suggestion. I may ultimately take him up on a suggestion he had offered when I started the thing to that he would create a counter to it a competing proposal that I could close my phone request and use his because he's done, he's done the vast majority of the technical work has been by him, not by me. And so, and that's, that's okay. I'm, I've still got to discuss with him because I don't know that I'm going to have enough time to do all the other things yet. So he and I will discuss it further. Thank you, Mark. By the way, by reading earlier today and your proposal, I discovered another dedicated vendor for Solaris or Solaris compatible. Yeah, that's something I didn't know of before today. That's pretty cool. That star Solaris is still alive and kicking. Interesting. Yeah, so who's the vendor. Oh, I'm not sure it's a commercial vendor. I think it's an open source initiative. Okay, maybe I totally misunderstood what I read. No, no, that's, that's cool. I'm just glad to hear it as well. Peter Tribble is still maintaining an Illumos Solaris. And so that that work is somewhat akin to the same work that is done in the FreeBSD project where they're where they they provide open JDK 21 as part of FreeBSD also and FreeBSD has it now also. So it's it's been positive. It's just that's not a particular vendor. That's just a port that they make available in Illumos. Yeah. Okay, so the Jenkins infra or community does nothing for that. It just happens to be there. Correct. Yeah. We don't we don't test it. We don't know nobody that I know of is an Illumos shoes or in the Jenkins community at all. Okay, got it. Next object is once again, it's for you, Mark, because the spring project made an announcement a few weeks ago about the last public build of the spring security framework 5.x next August. And about the spring framework 5.3.x, which is also August 2024, and we are not supposed at Jenkins to move to JDK 17 before October. If I'm not mistaken, so there would be some kind of a gap between August and October, if ever something terrible would happen security wise within spring. Am I right? Correct. Yeah, so you've understood it. The alternatives are as listed there that and the most likely is that if something happens in spring 5.x between August 24 and the end of October when it's end of life. We may have to patch it ourselves. That's yeah, we've we've done that before with other things. So if we had to do it there we could. I haven't started the discussion yet on the mailing list. Basel and I have been discussing it face to face, you know, to each other, and we'll continue that discussion there's more to do, and I will start the discussion publicly. In addition to here, because it's, we need, we need more planning and more, more effort on this it looks like it's going to be a large effort. Yeah, fingers crossed. We'll see. Thanks a lot, Mark. Now on to the release work on agent and control images, which means releases. So Damian told us earlier that we were still having some errors, problems, issues with Docker hub that keeps sending HTTP code for 29 errors. For whatever reason, I think we don't know yet if it's linked to a modification in our account or modification in the Docker terms of use or something else, but it's still happening. So the windows image for the latest weekly are not up yet, but the Linux images are okay as far as I know. And I've checked the Linux images and they are definitely okay. Cool. Good to know. So of course we had got since last two weeks to control weekly the 450 and the 451, which of course, agree to latest Jenkins weekly versions, but we also moved to a newer version of the bookworm Linux, and we removed the convert from json issue by simplifying that's just for windows images, if I'm not mistaken. It's linked to a more recent version of PowerShell. If I understood correct. Anyway, that doesn't change anything for the end users. We also had an LTS for the Docker image by the way I watched the video you made with there in pop lately mark and it was great. Interesting really. Thank you for that. So what happened within this image, we removed the dedicated when 19 from the update CLI script. I think you did that mark. Thanks for that. And it doesn't change much for the end user. It's just, we're not building any more dedicated 19. We also moved that even book more bookworm to a newer version and you benign to the latest version. So nothing groundbreaking for the end users. What about Docker agent. We had quite a few changes and a few version bump. And so we got three new releases. So it has been quite a few weeks or months since we had a JDK bump version for the Docker agent that because of her. It's a bug limitation. Something's changed within updates CLI lately and you now have to write down in the updates like manifest the complete architecture that you are targeting in the conditions for example you we used to work to write arm 64 or AMD 64 to check for the existence of arm 64 AMD 64 Docker images and Linux was implied and in the recent version of updates CLI that's not the case anymore you have to prefix with Linux or with windows or even worse for arm 32 you have to write Linux slash arm slash is seven I think so the manifest we're not working anymore and that's why we didn't have newer version of the JDK that solve mostly solved now so that's why we now have some newer versions. So we also upgraded to a newer version of bookworm and yes we got back official not not back because that was never the case we now have official Timurine build for Linux s 390x for JDK 21 because up to a few weeks ago we had only preview versions of Timurine JDK for s 390x and now that it's widely available, we can use official version for the s 390x. That's pretty cool because that also allowed the infrastructure team to have official JDK 21 images for our at 319x. The agent machines if I'm not mistaken they are from OSU OSL mark right. No actually they're donated by IBM. Damn it. But that's okay. Okay, an account that IBM lenses. But we do have some s 390x agents. We do. That is correct. IBM. Thank you idea. Now for SSH agent nothing really major we had just two version boom for bookworm linux and the kids version on windows. Now on to the work in progress for images we still have the long running draft adapter that you like JDK 1174 windows. It will work one of these days thank you have a first time you, you took on that. Now for the Docker agent three PRs are in review. The first one is an automatic one fired by update CLI about the newer version of the JDK 21 but that showed us it doesn't work and that showed that that we still have some work to do on the way we are updating our docker files and docker bake mark I think yes you were the one that saying that we had to do something about that. And then we started on several other PR that were supposed to solve the problem but some of them are not yet finished and yeah, we'll see. One of them was just a proof of concept. I think it will never ever get a merge but that was just to show that if ever tamarin was not able to provide us with recent version of dedicated 21 bill for arm 32. There are other vendors at least one other vendor that could supply us with a recent version of the dedicated 21 an official version. And that's something that made me think of the way we are building our images today. Most of the time we take an image from tamarin itself. It used to be a focal image now it's a jammy image and then we extract the JDK we run the link to have a customized or tailed version of the JDK and then we take a dbn image and put that binaries into that dbn image and we have, when we were experimenting with dedicated 21 we had preview images, and we did another way that tamarin was not supplying the human to base images so we took the official preview binaries for linux and then copy them directly after a gelling step into the dbn image we know that works. We'll have to discuss with the rest of the community but I'm not sure we should keep on using that human to image because it's sometimes it appeals sometimes later than the official binaries themselves. So whenever there is a CDE we could be faster to react when using directly the binaries instead of images but that's my point of view, you may not agree with that and that's fine with me. I think it's a worthwhile discussion so the question there is do we build from container images do we use a from clause to bring in the container image, or do we go after and download the exact binary that the, I was a little surprised that you haven't moved that one out of draft, because arm v seven as far as I understood it they've tamarin has said they're not going to do it, or has has that have they actually changed their statement. No, officially no. In fact it was in their roadmap. It should have been there but then they faced a problem with the TCK you know the test of the sweet. Yeah, it was not working, but then we saw that it was working for Liberica, for example, so we know that open JDK can work for on 32. And they would like some of them, some of the people in the tamarin community would like to get on 32 JDK 21 bills. But the thing is they have a limited amount of time as in every open source project, so they don't have the means to do it for time being but today I saw once again, it's toward Edison, you would also like on 32 bills for the 21. Maybe if we, we, you know, the tamarin users would need the guy so the Java effects and so on part of the JDK. So I don't know what that means. But maybe it's because they have a test failing in the UI part, maybe so maybe we could have a reduced version of the JDK. I don't know. I'm still in touch with Stuart. So we'll see if anything good happened from that. So yes, it's still in draft, because I'm not so sure I want to use Liberica for arm v seven. And frankly, I haven't heard a voice in the Jenkins community saying, I want an up to date JDK 21 Docker image for arm 32 I even don't know if I'm not the only one using the side. Mark, have you heard anyone complaining. I have not. So we still, you know, it's 2025 maybe when we'll have to move to JDK 21 for Jenkins. 2026, I think it's two years right we roll over every two years so so we still have plenty of time. Okay, and the last one is not really interesting. It's an attempt to track the human to adnibian LTS releases. I thought that that's what Damian wanted me to experiment with but I think I misunderstood what he wanted so we can forget about this one but this also made me ask myself, do we still want to use that human to dependency, or just use a binary releases, I think we'll have to discuss that more. Right. Now on to the darker usage agents. We have one PR that he's a long running run which is the bomb of the github FS version of windows, but there is a flaky test. And of course the time being is blocking the migration to JDK 17 and 21 for windows. So there are a bunch of things to do before being able to update that version of github FS. We also have the bomb JDK 21 version 2202 13 I think you mark detected that there was a problem. Because now after the 371 of 372, we can see that every time JDK 17 or JDK 21 are updated there is a flip flop in the Docker file because the Docker, the JDK version flips from JDK 17 something to JDK 21 something so that's whenever I made in the recent PR. So we'll have to correct that. And the last one is the one that we are using to move the Linux S3 19x to an official version and not a preview version. The thing is, the current version that is defined in the Docker files and in the docker bake, does not exist for S3 19x so we'll have to upgrade the version of the JDK and then we will be able to move the S3 19x to more recent version and official version for JDK 21. Okay, so that part could you I need to be a little more clear on that one so we're using 21.0.2 everywhere as far as I know. I'm not sure I understand then so, so. Yeah, the thing is we'd like to move S3 19x out of preview and into the standard one and the thing is the current version which is 21.0.2 something. What is it from. This is the one that shows the flip flop. Yeah, yep, you're right. My fault, I guess. So the 21.01 underscore 12 does not exist for S3 19x. Right, 21.0.2 13 does. Yes, indeed. Sorry, I was not clear. Okay. I mean, that's that's one where we could certainly do that. We could fix that problem interactively by by modifying that pull request to be acceptable so that then you can get get the thing released. Even if we don't fix updates even if we don't fix whatever's wrong with our use of update CLI. We can also wait a day I think that Damian said he had thinks he knows the solution for it and is interested in doing it so we can just wait a day. Yeah, that's why I didn't start it thought correcting it. I could have done worse things by the way but Damian already knows what he wants to do with that and he. Yeah, so it's let it like that until Damian fixes it. Great. Thank you. Let's go on to the Docker base quick start tutorials. So, Kevin, I think you merged before all leaving the multi branch pipeline tutorial so it's it's done. It's. Okay, it's not mine. I should have. It's directly on Jenkins.io. My bad documentation tutorials. Up. Up. Find it. Up. Yeah, sorry. Near the top. I think it is end to end. Yeah, because it's so big in order to share it so that other can read that I just don't recognize the page. So yes, it's done. And it's working. Thank you. And now I'm working on the main Jenkins installation. Thanks to the worker and hopefully will be able to do without Docker in Docker. We'll see. Mark, two weeks ago you told us that the unfair server run it first shot so it's still working. It hasn't burst into flames or yet. Oh, no, it's working great and I used it to do diagnosis of several problems over the course of the last few days where I would run tests in parallel and on it on it and on AMD 64 to check K is and it's behaving beautifully. Yeah, so it'll continue. I've got to discuss with the infra team how they want to handle it, because we could treat it like a static agent the way we do system 390 as a one off. We could treat it as a cloud cloud provider. We could treat it some other way, and it's up to them what what they would what they would prefer. I just need to discuss the, the opportunities it provides for cost savings aren't nearly as great as some of the other cost saving opportunities that the infra team is working on right now. So it's it's not as hot hot a priority for them. Yeah, of course, as their current projects. That's cool. Thank you, Mark. Oh, yes. Thank you a lot. Thanks a lot. Our colleagues for this opportunity. And last one we were supposed to receive a meal five pioneer board these days, but unfortunately the supplier has to deal with an inventory shortage of stock so we'll have to wait, but that's okay we still have lots of other things to do. Kevin mark anything else to add before we wrap up. Nothing else for me. I'll grab my sign. Okay, thanks a lot for for your time. The video should be available from 24 to 48 hours and see you two weeks from now. Bye bye.