 Welcome everyone, this is the Jenkins platform Sieg meeting where June's the 20th and today around the table we have a table, we have Damian DuPoto, Kevin Martens, Mark Waites and we'll see you later on if we see Kenneth or not. On the agenda we have one open item, maybe we'll close it, we'll see, we have a proposal for Mark, we have a little bit of work ongoing and we can make a small update of what has been done and I think that at the end we should be able to talk a little bit about the Docker hub stats. So as always it's been the case for many months now, Docker imagine and especially the Blue Ocean one, Mark we talk two weeks from now about the deprecation happening for Blue Ocean and the fact that you provided something within Jenkins that would allow people to know more about what they are running Jenkins on, I mean if their operating system is deprecated or the parts of what they are using is deprecated. So is there any progress specifically for Blue Ocean or not? No, the container images need additional work in the code so not yet and it will probably be several weeks before I make any progress there. Okay, no rush there but we decided that we would talk about each and every meeting until they sort it out. And I think that's fine, let's keep it on the agenda, I don't feel at all ashamed saying that I haven't made progress, we'll just keep talking about it. Fine with me, thank you Mark. Then you made a proposal to cancel the meeting for July the 4th, it's Independence Day in U.S. and maybe in other parts of the world. So yes, why not? Because lots of you won't be able to attend, fine with me, Damian fine with you. Okay, Kevin I guess it fine with you too because you're located in the U.S. So okay, let's get it done, we'll cancel that. So Mark you can remove it, you have the right to remove it from the agenda I guess. So thank you for doing that. And a short paragraph about what has been done lately on agent and controller images. Some parts of the agents and of the controller were not using yet update CLI, it's not mandatory to use update CLI, you can use renewable, dependable, whatever but I tried my luck and added a few things here and there to update some parts of the Docker images. So I have done a little bit of update for SSH agent. Thanks to the guidance and patience of Damian, thanks a lot for that. And also for the Jenkins controller image, so for them being we are tracking, no we are not yet tracking, it's not merged yet. I think, yes it is, sorry, I even can't read my own notes. So we are working to update surveillance part of the controller and for the agent images. Damian, would you have anything to share about that? The work is great, it's ongoing, so step by step. So I have actually had a question and with Damian here it's a good thing. So previously we were managing the operating system updates through Dependabot. This will change it so that now they are managed with update CLI rather than with Dependabot, is that correct? Exactly, one of the limitations of Dependabot is that it can only track the from instruction of Dockerfiles, while update CLI and Renovabot can track also arg instruction. So in any case, you cannot use Dependabot for tracking, for instance, the Git version we install on the Windows Docker images as an example. We have to choose and to carefully select which tool we use because from instruction is easier to read and maintain, but the advantage of the arg instruction is that we can specify it one from the environment and then use it on all the Dockerfiles. What we saw is that arg makes more sense even for the parent images because it allows us to keep track of it once for whole. And what we saw on the Docker agent image is that we can even factorize, we don't need to maintain duplicated code between gdk11 image and gdk17. So is there some hope then also to factorize similarly in the controller or is that not feasible? Technically, yes, that would be a good thing. But yeah, right now we focused on the image because less code on the agent images, sorry, it's also a good step. But then, yes, absolutely, that could be a nice improvement for the controller image. Great, thank you. Okay, so update CLI will see increased use and the benefit of that is we will then be tracking operating system versions and gdk versions with update CLI. Great, thank you. Yes, I was trying to force push the use of update CLI is just that I know nothing about renovated boat and not so much about depended boat and just a little tiny bit about update CLI that kind of works for me. So that's why I and of course I had discussion with Damian before that. I proposed that but it's not my own idea. It's just I'm just the one who implemented that with the help guidance in patients of Damian. That's all. Thank you. Anything else about that? No, cool. So now a little bit of a list à la prévère, we would say in French, about the latest updates for the Docker images. So once again, we have breaking changes for SSH agent, which happened in 5.4.0. And we are now with the version 5.5.0. And the breaking change and things for the pinning of the Alpine version, then the tracking of the Alpine Linux base version. Or was it the fact that we burnt Alpine Linux? No, no, I think it was a pinning of Alpine version. Damian, am I right about that? Damian? I don't remember exactly to be correct. Not a problem, it was not a trap. Whatever, it's a breaking change. Please have a look at the changelog if you're using that and note what is important for you. One thing that was awaited, I think, is the Git version bumping on Windows, which was kind of blocked because of the little update CLI bug, I think? Bug or lack of feature, whatever. Exactly. We updated the update CLI this weekend with the latest version and everything is going back to normal, including updating Windows version. So yeah, Windows Git version. So yeah. Yeah, that's pretty cool. Then there was also a Docker agent release, which bumped the Alpine Linux version and the Jenkins remodeling version. A new Docker in boot agent, which bumped the parent Jenkins agent version. And then, of course, a new Docker controller 2.410 because of the delivery of Jenkins 2.410. And now, a modification for Mark, which helps to download for mirrors and not from repo.jenkinci.org. I guess this has to do with the bandwidth reduction effort or is it something totally different, Mark? It does sort of. It was inspired by that, but the inspiration is not actually driven by any real data that says that the download volume is measurable or detectable as an appreciable change. It's not. It's just that we've already got a... We don't need to download everything from repo. And anytime we can download from our mirrors, we can actually make it faster for our users because there's only one repo, but there are seven or eight mirrors of Jenkins binaries all over the world. And for instance, my access to the mirror nearest me is significantly faster if I use the mirror than if I use repo. Got it. Thank you. It's a good practice nonetheless. Thank you, Mark. Any questions about the latest updates of the images? Okay. Fine. Now to the Docker hub stats. I had a look at the shared spreadsheet this morning. Unfortunately, after I made a stupid PR that created an Arc Linux JDK 17 image for... I even can't remember them, whatever. The thing is I had a look at the download statistics later on and so that the Arc Linux for JDK 11, for example, was not significant at all. So maybe we don't need to do something about Arc Linux for JDK 17 because nobody is using the JDK 11. So I don't know... Yes, you updated that once a month, I guess. It's kind of manual for the time being Damian, but it's useful, to say the least. Nice. So I guess that should ask or at least trigger again the question raised by Tim Jacob a few months ago about should we keep the Arc Linux image? Yeah. I've sent a tweet to the Arc Linux account a few weeks ago. I've never had any answer. No one jumped as fast as I can tell. So my proposal is that we start the process of removing a stop providing the Arc Linux image. My proposal is to continue on the issue that Tim started. And that might need to include a mark on your, let's say, tentative to mark some operating system as deprecated. Any occurrence of Arc Linux inside a container would trigger the message in an ideal future. Yeah. So as we can see, I don't have the name of the headers, unfortunately, but I see 3770 not very encouraging for that. So in the month of March, three only unique IP, three by type three. Yes, I guess we can forget about Arc Linux. So and that was the agent download, right? Is that correct? Yep. Because we don't deliver a controller with Arc Linux at all. That's what I knew. Okay. Yeah. Now, in terms of that is another piece of the deprecation thing. I'm confident that Jenkins has a way to let us tell users that the running and operating system on an agent that is deprecated, because there are plugins that do that, but that's not what the current thing does, right? The current one only warns about the controller operating system. But I think it's a logical extension to declare to the administrator, hey, someone in your environment ran a job that used a Docker container that is running a dead operating system. Are you sure you want that to continue? Nice. Thank you. So of course you can close if I don't do it by myself. My PR doesn't make much sense in this context. Anything else about Docker Hub stats, Damian, or anybody else? I need to update last month. I haven't done it yet. Say this, nothing else for me. Yeah, it's okay. I guess that we are not using it yet to its full potential. So we'll see. Maybe we'll make decisions later on based on that. But yes, all the time being, not so much. Thank you, Damian. Mark, Kevin, Damian, any open question or subject you would like to address during this meeting? Yes, the availability of the Windows image for the controller. We have one contributor that's requested that we update because for a lot of reasons that I don't want to details now, the Windows image doesn't provide any version tags such as 2.401.1-Windows. So we don't have this one. So it's always the latest. When you docker pool Jenkins slash Jenkins column Windows Server, you get the latest. But latest is Jenkins weekly version from 14, 15 months ago, which of course trigger a lot of red messages to the users. And the user complained for good reason about that. And the user took actions. And we have merged a pull request from that user as a short term yesterday. And the weekly release that we had today ensured that the pull request has an effect. So now the latest Windows version is 2.410. So that's the weekly release from last week. Now, the next step will be to update the Windows specific builds. So they will produce the expected tag and update the image. So next week, the goal is that if we can meet the deadline, we will have a weekly release 2.412 Tuesday. And we will have an LTS update. If we're able to learn that challenge before that, that means next week we will have updated version for Windows controller images. So is, this is a terrible thing to ask, but I'm going to ask it anyway, is there enough interest in Windows-based controller images for us to justify the work? So we've got one contributor that found the problem in 15 months or that detected enough of a problem to submit the pull request. That's great. That's a victory. Is it really worth it to us to continue that? I guess the answer is it cost us nothing to do it badly, right? It cost us nothing to ignore it. And if this contributor is willing to help maintain it, then it costs us almost nothing to keep shipping it. But there's something to be said for not shipping it at all. Help me out there, Damien. Today, each time we have a release, we spawn a Windows machine to build containers. So today it's costing us money on each release, in any case. We don't pay for the storage of the image on the Docker Hub, though. So additionally to that, we have the visibility of someone who won't try, if we have one user who reported the problem and was, let's say, good and patient enough to even propose contribution and make a contribution, that means we have other silent users. And the image of Jenkins of providing a default Windows thing to newcomers that has a big red warning is not good, though. So my proposal is that now that we have simplified the publication process, you have a tag and you build a version with that tag. The efforts to add the new tags and use that environment variable properly is simple. And for me, it's worth it because we already build and push an image every week. Your question still is a good thing. Should we keep using the Windows image? In that case, that will mean stop publishing Windows images at all to avoid costing money. The amount of money we are speaking here is almost nothing. I think, yeah, so, yeah, we could gain something but I would prefer having more exotic platform. We have one user that's enough. Then it's like our clinics. If the user disappear from the surface of our issue trackers, at least, and then we have issues, then we can stop publishing the image. That's all. But for now, we have someone active, so I would prefer following there, given the effort looks really easy there. Okay, so I would phrase it. I like what you're describing. I would phrase it even a little further. I would say, so long as we have a maintainer for the Windows image and this user who submitted the poll request is acting as though they are a maintainer, we may want to ask them officially, would you be willing to become a maintainer? That I don't know. But so long as we've got a maintainer, I'm okay with it. I think that sounds reasonable. If they drop out and no longer able to maintain or we find it becomes costly for our efforts, then we can consider dropping it. I think you're right that we will waste more energy communicating the end of life than we will just by bringing it back to life. Absolutely. I agree on that proposal. So if it's okay for everyone, then I propose that I will ask the user on the issue they opened on the controller image and ask them if they are willing to help with a safe message saying they won't be alone, but we need someone identified at least by default. I don't mind helping and being identified on the Windows port. I don't fear it now. So yeah, being to maintainer of that port, but I don't want to be alone and we need someone else than someone working for the Jenkins infra. Well, and I think that's the crucial element, is are they willing to help? We don't need them to carry the whole burden, but if they're unwilling to help, they say, no, I just don't have time to help. Then I think our answer should be, okay, we need to reconsider if the Windows container image is worth us doing. We appreciate your contribution, but it obviously was not important enough for the rest of us to have detected it for those many months. And since it was not important for the rest of us, we need someone for whom it is important. Thank you. Okay. Mark and Damian, I'm just kidding, but you said a few words that triggered me. Damian said, I'm not afraid of Windows containers. And you also said exotic operating system or something like that. So I was thinking, Mark, do you still have your Windows ARM64 machine? Yes, I do actually. Step right there. It's not supported for Docker. Docker CE doesn't support... And I don't need Docker. I don't use Docker on Windows ARM64. So absolutely, yes, I do still have it. And it is in fact still connected to my controller as an agent. Okay. I stopped writing my tracks. Okay. Anything else before I get another stupid idea? Okay. Looks like it's a wrap. Thanks a lot for coming. The video should be uploaded and available from 24 to 48 hours. And see you in a month from now, I'm afraid. And until there, see you on Gitter, Community Jenkins IO, or on the Jenkins mailing list, whatever. Thanks a lot for your time. And see you in a month. Bye-bye. Bye-bye.