 Welcome everyone, this is Jenkins Platform's SIG meeting, we're on the last day of January 2023. Today we have Mark, Wade, Kevin Mardens, Damien DuPortal and myself, Bruno Verashtel. We have a few open-action items in the agenda, the first one has been done, thanks a lot Mark. We had to find a better time for this meeting, which used to be on the Friday night, for us, European folks. And on Tuesday night, it's not even night, it's very beginning of evening, it's much, much better. So, I'm fine with us, thanks a lot, and it won't change, only if somebody asked to change it. So for the timing, the time we chose is perfectly perfect. Now, Damien, you're there, we have a few items for you. It was in the open-action item, I think we can get rid of it, but I just want to be sure. We had to talk about the platform support container, Windows 2019, Windows 2022. If that's done, Subject, can we remove it? Infrastructure area, it's done, we can execute Windows 2022 container, it's supported. But it's not done for the Docker image, we don't have a pull request. We have a pull request from a user that's never answered, so I consider that pull request being dead. So someone need to work on adding the new Windows support. However, before that, so for the agent, we can start working now, anyone interested can get started. For the support of Jenkins Core on Windows 2022, for that image, let me try to read it correctly. We should not spend time on this one, because we know that we have a publication issue with the Windows image. Jenkins Core hasn't been published properly since months. We have a user that is trying to help, that user is lacking information I try to give them, but it's not that easy. And we have an overall publication concern that image, so that will not make sense to start working on 2022, because we are not even sure if we will continue shipping these images. So I propose to put that on hold and remove the topic item on platform SIG for now, or put it on the backlog. I like that. I think we seriously should ask ourselves if we want to publish a Windows container image given that result. A Windows container image for Core. Agents agreed. Agent images, it makes everybody sense we're actively using them. But Core as a container image for Windows, question well how useful it is to the community. No idea. I'm using WSL. I guess lots of people use WSL when they are using Windows. I don't know about why and when somebody should use Docker for Windows on Windows. I don't know. If it exists, there is a reason for that. Certainly there is a reason. As an agent, it works very, very well. Or, okay, maybe that's too strong. As an agent, it works reasonably. And it's a little bit cheaper than spinning up a new Windows virtual machine, right? You've already got the machine running, you just take a container and run it. But why not a Linux one? Because I need to do Windows stuff. Oh, of course. Some people do. I know, I know, I know. It's hard to imagine there are those of us who actually run on Windows every day and who use Windows all the time. Okay. It's not Friday, you cannot troll anymore. We changed the day, you cannot say... Okay, it was even not a troll. It was a troll for me, I couldn't imagine. Yes, some people work on Windows and they don't have to, they choose to. And you're right. .NET is not a big one for us. But there are certainly community places in the Jenkins development environment where it is a big deal. And .NET on Windows is much better than .NET on Linux, right? The .NET on Linux port is a subset. Yeah, and I've seen some messages in the community discourse from people which are building for Windows with documents. Exactly, I want to build an MSI, I want to do all sorts of dark things. All sorts of dark things with Windows that are very Windows-specific, yes. And that, yes, exactly. Sorry about the troll, I couldn't have myself. Or update CLI to run an end-to-end testing with the Windows binary. We generate it on Linux, but we want an end-to-end testing to be sure that at least we smoke this thing. I know those terms. Okay. Thank you. Next, Damien, it's on you, this one, too. We talked a long time ago about the Docker image download statistics. I guess you've been so busy with JetFrog and so on that that's not the main subject you're working on. So it's still a thing. Should we have a look? Should we remove it from the open-action items? Yeah, so officially, yes, I have been busy. Officiously, not officially, I forget about that. To be quite honest, I'm sorry. I don't think it should be, I propose to move it to the backlog because it will be useful. But given that we added the new Ruby 9 image that we are speaking about Windows 2022, it means that we are not choosing metrics as a way to decide if we should or should not. It's not the main decision lever. It could help. It could be the main decision lever, but right now I don't see any urge of doing that. So I propose to move that to backlog, but not delete that absolutely because it could be useful. I'm not the only admin, so I need to check with admin, but I think there will be other people who could access that or better. I could create accounts if it's okay with only the ability to read these statistics. As far as I can tell, with the plan we have, we might be able to have accounts with only this permission. So people who won't be able to write or push images only get the statistics. Okay, and as we have two members of the community which were found of statistics, Jean-Marc Messain, Adrien Le Charpentier, maybe they could use that account. Absolutely. Thank you. Now, another big and long subject. Merging the Docker agent repositories into a single one. I don't know if anything has progressed with that subject. Not yet. Should it still be an open-action item or do you want it to be in the back? Yes. For me it's a top priority item for the platform SIG. Cool. Thank you. Now, the Docker image is the one for Blue Ocean. We've been talking about this one for a few meetings. Is there anything new, Marc, or Kevin, or Damien regarding this image? Are some people still talking about that or just maybe everybody forgot about it? It's not that I've forgotten about it. It's that it's not been nearly close enough for me to do any work on it. We do just need to announce its deprecation. Go ahead. Sorry, I meant end users, not people which were supposed to work on that. No, just people asking for some help or some news or anything. I've not seen any further requests in a month or more, not on community.jankens.io, but of course, if they ask on community.jankens.io, Gavin Mogan very promptly tells them, just like we do, that that container image is deprecated. So he's carrying the message very nicely. We just need to make it official. Yeah, thank you. So should we keep it in the open action items or move it like a cycle log? Let's keep it on the action items because there's benefit to us to get rid of that. Definitely. But later on in the document is written, you have to talk about that each and every meeting. So we do that. Okay, yeah, just there. Got it. Thank you, Mark. Now, contrary, it's still in the open action items so we can get rid of that. And thanks for Windows. We also talked about that. So yeah, it will go into the backlog. If you don't mind. Butchering the document. Now, ongoing work with Docker images. So I've seen quite a few changing these latest Docker agents. But we also have new platforms. It was from the last meeting, I guess. So maybe we could get rid of that now. We know that we have Windows 2022 available thanks to Stefan for the infra. Yeah, I would actually phrase this one is, for me, this was container images. And so for Windows 2022, we don't have it. But you could say if UBI 9, we do have. There is clearly a new platform, UBI 9. How do you call it? Do we write it? Yeah, that's great. No, UBI and then the digit 9. No, no, no, no. Yeah, sorry about that. Exactly. With JDK 17. Maintained by Oliver Gonja of Red Hat. Okay, call for a TSM, but got it. So real old. Sorry. G-O-N-D-Z-A. G-O-N-D-Z-A. The J, the Ilung. The later. That one needs to be a exact, perfect. Spell to the exact. I can go get help. A-B-C-D-E. I get it. Yeah. Right. He is also the maintainer of the UBI 8 container image. So it's a good fit. Got it. Daniel, is Wolfi still a subject? Or are we still thinking about that? I wasn't present when the topic was raised on the platform. I'm sorry for that. I think that will be worth walking with that or asking the person that with Chen Gardeuve, who built a preliminary example of Chen Ginseng and Jankins agent. That will make sense. The reason is that this specific definition will help people who want to run Jankins without taking many risks. So it's not for people that require Sun2S for the container image for whatever administrative reason. It's for people who really want to rely on something that should be only as small as possible and as secure as possible. For people like me who don't know much about Wolfi, could you tell us in a few words what it's all about? So the idea of Wolfi is saying, when you provide a container, having multiple operating systems not only is a nightmare, but also is a risk. Because most of the time, what you add on the container, you can control if there is a CVE or a security issue. And you had yourself and you should be able to say, I need this particular set of dependencies that I control. However, the dependencies that come from the upstream image are risky. Right now, if you run a security scan on the latest Jankins image, even the one we just published, you will have a bunch of CVE or security adversaries and tools that we don't even use because they are part of the default Linux distribution behind. The idea with Wolfi is that you only install, build and run what you need. So for Jankins, you only need a GDK. You only need a Ventually Curl for running the script shell supports at the beginning of the image. But you'd only need a set of tools that you can exhaustively define. It's in the area of the new S-BOM trend. I say trend in a neutral way. The S-BOM is a field of material is to list what is exactly inside the image that also help on the area of build reproductability if you want something to be rebuilt. Because each time you run an apetite get package or apk add, you can create mayhem in the dependency chain. So Wolfi is an operating system that has been built only for running inside containers. It's not aimed at running machines. And within container it reused part of the Alpine apk package system, but also it work a bit like Nix. You compile and build each of the tools you need and you create your own dependencies. So, would it be, sorry to interrupt. Would it be a good comparison or totally bad one talking about the old Linux from scratch that we experienced with years ago, but just for containers with a very small subset of tools you need. That's the same idea, but only containers you said and with tools that normal human can use to extend the image if they want. Thanks a lot for the explanation that was crystal clear. Oh, if you ever have finished with that. I haven't done it yet. No, that's okay. So, just to know chain guards people, I assume some former Jenkins and Jenkins 6 contributors, they have built, let's say, test images of a Jenkins score using GDK17. I think it's the T-Marine GDK17, but not sure, where the amount of security advisory from the chain guard security scanner has drastically decreased. Like you have one or two instead of hundreds. Like drastically. Okay. Oh, that makes more sense. I don't... Please be with me. I'm not saying we have security issues with Jenkins image. I'd say the scanner points a list of potential security issues that can or cannot be exploited. They don't give you actionable on what to do with this. Yeah, which are part of the latest Debian, the latest Ubuntu, the latest Alpine and so on. They are there. Absolutely. Cool. Oh, thank you. That's interesting, really. And regarding oclinox, oh, sorry, go ahead. I'm just... My skepticism kicks in here because of past experience with Linux from scratch kind of experiences, right? Linux from scratch and its variants, the free VSD package system, the open VSD package system, those things are notoriously challenging to maintain and make portable. They take a lot of work. And Wolfi is a young project, right? I mean, free VSD's package system is a very mature project. Arch Linux is a very mature system. Wolfi is, for me, still brand new. And I'm hesitant to jump on to it yet. Yeah. The thing is, I really think we need, if we want to be cloud friendly, to go in that direction because Wolfi is clearly a way to have some exposure, to validate some behaviors of Jenkins, to clean up the list of dependencies we need on the Docker image. We will clearly benefit from trying to fit Jenkins into Wolfi. We will learn from that and we will improve all the other images by saying, oh, we need that dependency. And I've got a real-life example today, Git. Which version of Git is installed on the latest GDK 11 image of Jenkins? 0.30 something? No, it depends which is the base operating system for the container. For Debian, it's one version. For UBI 9, it's another version. For UBI 8, it's another version. For CentOS 7, it's a terrible, awful, evil version. Of course it's CentOS. It's CentOS 7. So yes, Damien's point is correct. If we take responsibility to deliver the version of Git we prefer, we would switch and always deliver the most recent release. We would be delivering Git 2.39 and not care about the operating system vendor. And that's what Wolfi, and I agree, that's Linux from scratch and Wolfi both give you that benefit. You get to choose. I want Git and I want it from the latest release. Yeah, the thing is I don't think as much as you do, Mark. I don't have that much experience either. As soon as I see something in you, oh, look, a squirrel. That's the way I'm interacting with Wolfi. I got a proposal here because we are all busy and that kind of thing should not rely on the four of us. I think we should ask people at ChainGuard and tell them if it's okay and if there is no objection. But my proposal is we ask them that we are okay to introduce a new image. And so if they are willing to open a pull request on the repository, we can get started and spend time on reviewing and understanding it. The way I see it is that we know what we don't know. So if they open a full request, we can then start the discussion on, oh, how can we document to end users? Hey, I got, I'm a could use Wolfi image. If I want to add the AWS command line inside that controller image so that Jenkins can do whatever with that, with the controller level or Kubernetes, some plugins requires that or would help. What would be the path? What is the documentation on Wolfi that helps me to install or build myself AWS dependency so I can build it? That's an example out of the world. But the goal is that we can focus on that part as reviewers and maintainers while people who already have the experience on Wolfi could get the heavy lifting. They already did it so they could provide things and we just have to package and polish that and get started with that first iteration. What do you think? What do you mean? Sounds very reasonable to me. Is there someone volunteering to contact them or should I do it? Because I volunteer as a foldback because I'm interested, but I don't want to step on someone else too. So if you want to contact them, I don't mind either. I'd love to have you do it rather than me because my biases lead me away from it. I think your interest leads you towards it and that's a good thing. So you see it as a positive and I like that. I'll change that into David. Oh, you can keep working for whatever reason. Sorry. Okay, thank you. Why are we talking about new platforms? Can we talk about Arc Linux? I know it's linked to the statistics we don't have yet about the usage of the different images, but is it still a subject should we duplicate Arc Linux or not without having the numbers of the loaded images? I think we should. But again, my bias is to remove things that I am not persuaded are of value. I also think we should start announcing the end of life of the CentOS 7 image. But again, you're hearing my biases being echoed loudly here. Yes, I was saying it would be perfect where there is nothing more to remove from. So maybe removing Arc Linux will make Jenkins containers just a little bit more perfect. I don't know. Okay, Damian, Kevin. Okay, I don't think it's worth it's deprecating. It's right now we have at least one person using the base image. Ooh, okay. Nice. Last time, if that's okay for everyone, we'll move on. We talked about Mark, talked about the Debian 12, which is a bookworm that will not deliver OpenJDK 11. I don't know if there's anything new. And by the way, I thought I knew a few things about Debian, but I learned this morning that all the name of the distributions were linked to, what was it, comics? Story story. Story story. Yeah, I didn't know that. And that's why Unstable is seed, which happens to be the bad boy at the neighbor of... Anyhow, I didn't know that. Now I know and I maybe will quit using seed. Okay. It was from Veronica Explains, which is a YouTube channel I happen to watch from time to time. Anyhow, Mark, any news about that? Yes, so further more details. I've learned more since having further discussion and looking at end-of-life dates for OpenJDK 11. So end-of-life date for OpenJDK 11 does not happen until at least 2027 or 2026. So it's got a nice long life ahead of us. So there is not an urgent press that we need to drop JDK 11 support for Jenkins. But I still think we are doing the correct thing to say that in April or May, whenever they release Debian 12, we will change the Jenkins documentation for Debian and for Red Hat to describe how to install with Java 17. It's fully supported. It's already fully supported. And there's no reason we should describe Java 11 when Java 17 works so well. I got a question. When you say OpenJDK 11, are you referring specifically to Timurine Distribution or the Distribution package by Debian when you have to get installed OpenJDK? So when you do an apt-get install of OpenJDK, the package provided by Debian, the Debian project will not deliver OpenJDK 11 because I assume it's because they don't want to have the life, have it live longer than they have to support it beyond the end of its life or their operating system. Okay, because the thing is that we don't use that package today. Well, careful. Our installation instructions on Jenkins.io, you use that. As does our package install instructions for the dev package. Now, you're right. Container images don't use that. And we highly recommend container images, but for those who are using native package installers, we do continue to use the operating system packages, both for Red Hat, for Suzy, and for Debian and Ubuntu. Yeah, and on smaller machines where having a Docker container is slightly overhead that I can't use, I have to use the ones with packages which are provided by Debian or Ubuntu. By the way, is a PPA for Debian and Ubuntu the same for the OpenJDK build or not? I've never tried to use a PPA, so it's not a PPA, it's actually the OpenJDK. The OpenJDK package is actually provided by the Debian operating system, so it's not a separate thing that I have to do anything to enable. It's built by the Debian maintainers and validated by them, especially the leakers. Validated by them and maintained by them, and sometimes that was a detriment actually. There was a period five or seven years ago where they made a mistake in their maintenance of the JDK and that mistake caused some unexpected damage. Yeah, so it's actively maintained by the people on the Debian project. Okay, but this sometimes different depending on the platform of the CPU architecture, for example, I'm just thinking out loud about my RISC-5, which uses a zero VM from the Ubuntu operating system. And if I were to install that on another CPU architecture like R64, for example, it would be a hotspot enabled machine. So yeah, take care with what you are downloading from the operating system. It's not always the best JDK you could find for your system. Correct, right. But in this case, the benefit to our users, we're going to document Java 17, and we're going to recommend that they use Java 17 by documenting it. We will drop support for Java 11, and we'll continue supporting both. But there will come a time in the future when the Jenkins project will have a Jenkins enhancement proposal that will eventually drop support for Java 17. It's just not likely to happen any time during calendar 2023. We don't need to rush it. Of course. Thank you, Mark. By the way, will we one day or the other talk about Timurin because we're using it for our container images, but in the official documentation? Does it make sense not at all? Or do we have some kind of partnership, or do I know we have the list of the supported JDKs, but I don't know. Should we talk more about Timurin or not at all? That's a good question. Maybe let's bring it separately because you're right. We don't. I don't know of any place where we actively describe in the Jenkins documentation our intentional choice of Timurin as the container JDK, but it may be there and I just forgot. I think that's a good idea that we have made an intentional choice there to use Timurin and the choice was made actually I think in the platform SIG because Timurin provides the platform, supports all the platforms that matter to the Jenkins project. 64-bit ARM, 64-bit Intel, and System 390 are the three architectures that are actively supported by the Jenkins project. Our container images deliver at least some variant of each of those three. Thank you, Mark. Now, JDKs support for Jenkins require Java 11. Is that still a subject? No. Actually, I am proud to announce that the Jenkins enhancement proposal proposing to require Java 11 is now final, which means completed, done, merged, everything. So for Java 11, for require JDK 11 is final. So we have completed all the steps. Congrats on that, and thank you basically, I guess, for your input. Thanks very much to Basel, to so many others. Damian, once again, it's for you. Don't be mages. So you think that's still a thing? Yeah. Fixed. We found the issue. We migrated the deployment job on Trusted CI, and we were able to validate that the latest agents were picked, and we checked manually each job to see that there is no Git ball features from past years that were enabled. So we cleaned up that up, and that's okay. Three days ago. Wow. That's a major step. Okay. Now, JDK 19 available, that means on the infra. Am I right? Yes. Frick. Sure. Yeah. So it's done. Yeah. In infra, it's done. It can be used by people if you want to test. I don't see any use case for the platform because it's not an LTS version that should be the JDK 21. So I don't see any reason right now, but I might be missing use cases. Don't hesitate to add them. So that's why I propose to put that topic as done. Yeah. Maybe for some people, like me who have too much time on the hand and won't test their piece of software with JDK 19 or 20 to see where it will fail, not if, just where. That's a good idea. Oh, some news for the IBM S319X mark. Okay. Yeah. So, and that one has been merged. So I submitted that. I'll include a link and Bruno, you can just click the link to see it. It's a little more dramatic than I had intended for it to be, but click the link so everyone can see it in the recording. So the system 390 agent may restart one or more times Friday the 3rd of February from 4pm to 10pm eastern time in the United States. Got it. The red text, the issue is not resolved yet is accurate. It just, this is, I tried to choose the least severe of any of the options and apparently that still shows issue is not resolved yet rather than showing that the window starts this Friday. Okay. And the website is not that precise. No shame. It's a static website, right? Since it's a static website, it can't be time dependent. Oh, and you're all saying in the next sentence that state automation jobs are only known users. So even no human being will read what you just wrote on the website. Correct. I documented there as practice for that way people know if somebody were surprised. They could see it on status.jankens.io that the agent was restarted. Perfectly perfect. Thanks a lot Mark. Yes, we've seen some updates for Java in the containers. Am I right? So they're not just in containers on all the infra. These updates are deployed to all all Jenkins infra throughout all of our container images. Only one exception. Windows containers. Oh, okay. We have unchecked because when we deployed the rest, the official image for Windows weren't available. At least the support for Nano server. We are watching that. But every other builds are able to do it. Great. Nice. Thank you for that. Kevin, Mark, Damian, anything else to add before we close? No. Okay. That's a wrap up. Thanks a lot for being here. Oh, yeah. Go ahead. Thanks for driving that. Thanks. Thanks very much. You're welcome. The recording should be available from 24 to 48 hours. And see you two weeks from now. Bye-bye.