 Hello everyone, this is Jenkins Platform Sieg meeting November 21, 2023 and today around the table we have Mark Wade, Kevin Martens and myself, Bruno Verashten. Today as always we have one open-action item, then we'll talk about the Java 21 support within Jenkins, then we'll talk about the latest changes and the work in progress in the Docker images we supply and just a quick agenda note, we'll discuss that maybe in the end, I won't be able to host the December 19 platform Sieg meeting, so if anyone is available to host it, you're welcome. So first thing first, Blue Ocean Docker container, so it's still outdated and maybe even dangerous to use anyhow, we should find a way to announce it more than what we have already done because it's deplicated, you should not use it anymore. Now on the Java 21 support, Mark, what about the progress on your Jenkins enhancement proposal? I saw earlier today that it was not, it's merged the GitHub way, but I don't know if that means it is merged. Oh, I didn't know it. No, no, as far as I know it is not merged and I don't actually want it to be merged yet, so if it were merged, you would see instead of JEP000 at the top, you would see a number like 238. Okay, I was wondering, I don't know about the JEP, I thought that it was merged because it's part of the official repo, but that's not what it means when it goes to official JEP. In this case, what you're looking, what you see actually is probably a view onto my repository, not even onto the official repository. Oh, it's written just as part of the, yeah, so you're viewing the pull request. So what you're seeing is the pull request and you're seeing the pull request in context, which is good. And so this, the more work that needs to be done here, it needs a much more detailed plan on what it means to, well, on the detailed steps we take to add a Java version, those are relatively fresh in our minds. We just added Java 21, it's a matter of me extracting those, documenting them. But then the much more challenging one is, what are the steps we take to drop a Java version? And that means going back to the time when we dropped Java 8 support to see, okay, what were the steps we took and what are the changes that will be needed in current code in order to allow us to do a smooth transition when in October of 2024, we stopped supporting Java 11 and go strictly to Java 17 and Java 21. So, so yes, there's still much more to do here. Now, as for the top plugin testing with Java 21, I counted all your, I found 44 instead of 36 that are officially tested with Java 21 in the intro. Okay, so now your number is very different from mine because I get a count of 70 of the top 250. Already merged and working? Yes, already on the master branch. So let me do a double check. I'll do a grep minus big, let's see grep jdk colon dot star 21 star slash Jenkins file. So if it's Oh, are all of the ones you are counting from the list we had previously or not? They're as far as I know, they're from the top 250. So I think they're from the list, but I could be wrong. So it's your measures and my measures are different. That means I need to go do some more research to understand. Yeah, but mine could be wrong, right? So leave it, leave your 44 there because you were using a consistent counting method. So what I see is I know that I know that we have on my list. So I've got a list of 100 and let's see in my directory, I've got 113 repositories in the directory and in that directory, there are Oh, sorry, just a minute. I just ran this 43 of them that I have 43 of the 113 that aren't definitely not merged to master yet are not merged to their primary branch. So so there are for sure, roughly one third, a little more than one third, no roughly one third of the repositories I'm tracking where they haven't merged the change to the master branch, the job is passing or is there but it's not been merged. And then like your number the 13 that your cursor's on right now, I have two, four, six, eight, 10, 12. Yeah, exactly about that same number. I count 15 that were on my list of plugins that don't yet operate with Java 21. And so that we're in the same rough zone on that number. Got it. Thank you, Mark. Oh, that takes chance. That's too bad. I had written something to ask you know, regarding the S 319 X, for example, so it's not in the official general availability release yet. So it's a jdk 21 dot or dot one plus 12. But it's back in the jdk 21. Oh, dot one plus 12 plus one something a beta. So it's still showing up in the nightly builds. And I think it will be like that for quite a while because it's not, it's still not passing the general availability test. That's why it's not showing in the official release. But that's not really a problem as we are supplying images in preview mode for all the platforms where the general availability jdk team are in build is not available yet. So everybody should be able to use jdk 21 with a preview version of a GA version. It's available. And impressively, PowerPC is available in a released version. Yes. And even R64 for Alpine, which is not one of their main target, but right there. Go figure. And we are still struggling to get the URLs right in each and every repo where we're using tamarin. So Damian is working on a way to use tamarin's API, you know, to find the right to help to download binaries. When I say working is working in a fork of a VTI. So the pull request, we show up one of these days and should help us having something easier to work with. And there's a general move. We'll talk about that in a few minutes. We would like some of us would like not we at the whole community, but some of us would like to not rely on the Docker images supplied by tamarin anymore, but to their binaries, but we'll talk about that in a few minutes. So now let's switch to Docker images. So up to now. So we were using tamarin's Docker images. And frankly, in the last month's what we've seen is that the Docker images supplied by tamarin are pretty late. They come in late into the process when the binaries are already available on GitHub in the release section. It's it takes some times up to two weeks to get the corresponding Docker image. So it's kind of a problem for us, especially because we are using update CLI in lots of cases. So update CLI detect that there is a new version of a JDK build for tamarin. And then it tries to verify to check that the Docker image corresponding to that binary is available on Docker hub. And it's not. So it's failing. So we don't get the update we would like to get. And that's a pity. That's one of the reason why we should maybe switch to directly use a Debian or something base image and then build on top of it an image with just importing the tamarin binary ever since you're there, would you like to tell us anything about that move from using tamarin images to use a base image on top of which we install the tamarin binaries? We have both situations currently on agent, for example, for JDK 21 preview image, we are using we are downloading binaries that we are copying and setting that on on a base image. So the move won't be won't require a lot of effort. And it should be transparent for users since we are from the we are copying the JDK and yeah, it's running on the base image. So there shouldn't be any big difference. No, I think in the end, the users will get the very same thing, except they will get it much sooner with the latest move just because tamarin is pretty, yeah. Yeah, it will also simplify the dependency management updating a image and yeah, so it should be a good move. We'll see. Then on the controller we had a weekly last week, like every weekend this week too, and we also had an LTS 2.4 26.1 and something is breaking or it's a breaking change. Mark, I know how much you love CentOS 7, so you removed CentOS container images in the latest LTS, right? Correct. That's a good thing. I think they were removed a little bit before that, but yes, we no longer deliver show host 7M images, the container images they exist still, but they will are no longer updated and there will be no updates in the future. Yeah, I know. Can you close for the TD show in C2K repository? Oh yes, absolutely. I thought I'd closed it, absolutely. Yeah, cool thing. And people still using CentOS 7, if you can, please switch to a more recent operating system. You'll do yourself good by doing that. Hervé, you also brought a breaking chance because now Java 17 is a default in the Windows images, right? Yeah, the change has been introduced in previous weekly, but it's first SDS with Java 17 as default. We are now publishing both Shilika 11 and Shilika 17 image, so users can still use Java 11 if they need to for a Windows controller, which is not that frequent, I think, but yeah. And most of the changes come from the reflector process. We have now the possibility to build multiple SDK. We can easily add a new Windows version like LTS 2022, add new flavor like none of server if needed. I don't think so, but yeah. And they have now a proper set of tags instead of just two tags every time the same and without any Jenkins version in them. So users can now pin their Jenkins version if they use Windows for controllers. Yeah, that's pretty cool. And when you say refactor, I think most of the job is going from a PS1 BIOS script to Docker bake. That's right. I'm using, I switched to a process like the one on Docker agent and Docker ingrain agent, which is using a Docker compose file as source for the image definition and tag to you to publish. So that should be easier to maintain too. That's pretty good. And when the code bake will be supported on Windows, which will be easier as we can use the core compose file to build with the code bake. So we need to create a bake ICL file for Windows. Okay, pretty cool. So for the end users, what they have to remind is that if you don't use a specific suffix at the end of your image, you will now switch from JDK 11 to JDK 17. So beware. Important not to the tags that have changed. So before there wasn't any mention of LTSC in the tags. So if you, if Windows users don't change their Docker commands, they will remain on old image. They have to change the tag. Hopefully they are reading the change logs. Then we updated the Debian Bookworm version. We also changed from JDK general availability version, which was 21.01, sorry, 21 plus 35 to 21.01 plus 12. And I saw earlier today that there is a JDK 21.01 plus 12.1 in the work. So more work to do, or maybe it will be fully automatic. We'll see. Then Mark, you introduced the very last version of the JDK 17. So 17.09, underscore nine. Same for the JDK 11 by RV. And we also bumped UB9 to another version and UB8 also. Then I think it was last week. Marvin Ruder, sorry if I mispronounced your name, he came in into the SSH agent repo and entered a new issue. Well, there are some general availability images available for Tamarin. And this is not reflected into the SSH agent repo. How come? Please do something for me. And we asked him, well, would you like to contribute? You know, you could be inspired by all the repos from the Jenkins organization. And he did it. He made it. So he made a pull request, which has been merged, but which hasn't shown yet in a release if I'm not mistaken. Right, Ave? I don't think we released a new image, but we can do it. I don't think so. But so we now, he updated a few things and we now have four of the SSH agent images where the JDK 21 general availability image is available and all the images with previews for platform where it's not available like the S319X, for example. Good work. Excellent work, Marvin. Thanks a lot. We do like that kind of interaction with people from the community starting with an issue and then proposing a PR if the dream of a maintainer. Anyhow, on the windows, sorry, on the Docker agent, we had the windowscript cleanup. So I guess it's also you, Ave? Yes, that was some progress that were between some timer. I have some stuff to do again. I want to replicate what I've done on the controller image, like using Docker compose file for the tags. But many what I'm working on is merging both Docker agent and Docker in one agent using a single repository and a single Docker file for both and allowing us to publish both these images at the same time instead of publishing Docker agents and waiting for the container publications and going on the in one agent waiting for the deeply request machine it's publishing. So everything will be done at once. I've got the windows build running and publishing images as I want. And I have to look to do the same for the windows build. Yeah, that's a very interesting project. We've been talking about that for months now. When it will be done, yeah, it will be a less tedious task to get everything synchronized and published as soon as possible. Thanks a lot for that. Now for the inbound agent, we had a few version bumps here and there. And so we got a few new releases, or just one new release icon. Yeah, I think, yeah, just one new. Yeah, super intimate, I think. Yep. And that's all that I had, except for the agenda problem. So I won't be available on December the 19th. So if any one of you would like to host the meeting, that's fine with me. If not, we can just cancel it, console it or postpone or whatever. As you please, we still have some time to discuss that asynchronously if you want to. So no need to raise your hand just now and say, oh, I'm doing that. We'll see. Is there anything else? Yeah, I'm even willing to raise my hand now. So I think I can cover it. Oh, thank you so much, Mark. That's cool. Thanks for your help. Is there anything else you would like to discuss? Would you have a comment or an announcement to make or anything related to the platform's meeting? Okay, I take that for a no. So let's wrap it up. Thanks a lot for attending. The recording should be available from 24 to 48 hours. And see you in two weeks. Bye-bye. Bye-bye.