 Hello everyone, this is Jenkins Platform SIG meeting. Today we're on the 13th of February, 2024. Today we have Kevin Martens, Kenneth Salerno, Nick Raimann, Akash Mistra, welcome. I think that's the first for you. And I think I forgot nobody. One, two, three, four, five. One, two, three, four, five. Yeah, there we go. And myself, of course. So today, as always, we have one open action item. We won't talk a lot about Java 21 because Mark won't be able to join today. And I don't think we had lots of news. We'll talk briefly about the release work on agent and contrary images. Then we'll see the work in progress on images. And then at the end, we'll talk about a unique proposal to implement Logify generation plugin installation manager tool. As always, don't hesitate to interrupt me if you have something to add a question, whatever, feel free to interrupt me. Let's start with the open action items. As always, we still have two announced in a way or another, the end of the Blue Ocean Docker containers, or container containers, I think there are several of them which are outdated and it's not really a good idea to use them anymore. It's not directly the Blue Ocean tool. It's the containers built on top of the Blue Ocean tool and have a replacement in the work which happens to be, how is it called by the way? Pipeline graph view, I think. It's not all the features of Blue Ocean are there yet, but it's a cool work in progress. Anyhow. Now let's go with the Java 21 support and the 2 plus 2 plus 2 Java support plan. So the goal there is to let the Jenkins community users know how and when they should change their Java version and how will Jenkins propose to support a specific Java version and for how long? So the term mark point is 2 plus 2 plus 2 and there are links there to the Jenkins enhancement proposal which is not merged yet. There was a long way to go. In fact, as soon as some other people joined in the conversation, they bring some new ideas and yes, it's not finished yet. And a few weeks ago when we were in Fuzz and Brussels, we had the day before Fuzz and Jenkins contributor summits. And of course, people brought some new ideas. So, yes, we are not yet to see the end of it, but that's really interesting. When we think that two years ago, we were still working with Java 8 and now we know that Jenkins works with JDK 11, 17 and even 21, yes, these are great time for Jenkins and Java. Now let's switch to the release work on agent and controller images. So we had, of course, two controller recalls, the 2444 and the 2445, but there were some breaking changes. So if you are using them on a daily basis, please take care. We replaced the Java 21 previews with release version for some of the architectures. From the top of my mind, I think it was about PPC64LE and maybe S390X. Something like that. So Mark, wait, work on that, but also Kenneth, as you're there, can you confirm that I'm not saying bad things about that? So it was Mark focused on the S390X and I think you proposed the modification for the PPC64LE. Correct. Correct, thank you, Kenneth. So thank you for your work, by the way. We also removed the RMV7 for the controllers because yeah, it's not such a good idea to keep this kind of machine warning Jenkins controller when we know that the Tamarin project won't supply anything newer than JDK 17 in the coming years, except something magically happened and then we are moving to JDK 21, but I don't think it will happen soon. By the way, at first then I made some two-world Addison, I think from the Tamarin project, who confirmed that it was not scheduled to do something regarding ARM 32 and JDK 21. So yeah, definitely not a good idea to keep trying to do something with these machine for containers. And frankly, to be honest, they aren't that many machines, ARM 32 machines able to run efficiently Jenkins controller. It works, but it takes so much time, it's almost unusable. So yeah, I'm fine with removing these images. And of course we had a few bumps for the dependencies. So we moved plugin manager to 2.12.15. We bumped UV8, Debian Bookworm Linux with the latest version. As for the Docker agent, we only had one new release, which changes something which won't have any impact on the end user. Like for example, the definition of tags in Docker Compose, but there are some modifications that will impact end users, which are not breaking change, but we updated the Java versions and the Debian version and also the Alpine Linux version 2.3.19.1. In downed agent, it will take a few meetings for me to understand that it has gone. It has merged with the main agent repose. So it's not updated and that's perfectly fine. It does not exist anymore. Now for the SSH agent, we had a few version dumps which led to one new release where we modified the Debian Bookworm Linux version and Alpine Linux version 2. We had quite a few work in progress weeks before on images, but there is only one still a work in progress. It's only a draft for the time being and no pressure on heavy, not at all, but it's still working on adapting the JDK 11 and 17 manifest for Windows. And in the end, that won't change anything for the end users, that just internal changes. Now the Docker base quick start tutorials. Before first them, we were able to merge two tutorials about Maven and Python. So it's a rewrite of the original tutorials which were using Docker in Docker and pretty, yeah, it was difficult to follow. Frankly, you had to know Docker before starting the tutorial, which is not so cool for first time user of Jenkins. Some people managed to do that, frankly, but that was unnecessary. So we are rewriting one tutorial after another and the last one, it's not the last one in the list, but the last one we are working on is the one about Node.js and it's progressing, but slowly. Any questions or remarks? No, not yet. Okay, thank you. Then, Nick, the floor is yours. You proposed on the GitHub channel, I think, to implement the log file generation in plugin installation manager tool. So could you please tell us a few words about that? Yes, this is based on a longer conversation I had during the Jenkins contributor summit with Mark, who unfortunately isn't here today, as mentioned. And I did kind of mention it briefly in Gitter, but there's not a lot of background, so I apologize for that. But what we talked about is the potential feature of having something in plugin installation tool to generate a log file. So for developers that are familiar with Python or NPM, I think these are two language environments that commonly use log files. I'm primarily a Python developer, aside from Groovy and other Jenkins stuff. So in Python land, the tool that we use is called pip-tools, and specifically pip-compile. And what you do is you give it a file called requirements.in that basically says, here's the packages that I really care about. And typically this file is unversioned. You don't pin any versions in it unless you have some very specific needs. And then you pass it to pip-compile, and then basically the job of pip-compile is to generate you a huge file that has all the actual requirements to pin versions. And so that means basically the packages that you wanted and their dependencies and their dependencies, and so on. So the goal of this is that you have a requirements.txt file that can be used to say, okay, here's all the packages I want at very specific versions so that when you deploy your software into the wild, you know that it's with a set of packages that are tested at specific versions and there's no surprises. Obviously there's a strong desire to have a similar feature within the Jenkins plugin installation manager tool because although you can rely on that tool to update your plugins regularly, it has a few disadvantages. Namely, you don't really... It's not always going to be guaranteed that you maintain compatibility. For instance, when a transient dependency gets updated, you're not going to be assured that another top level plugin has that one. Also, if you decide to remove a plugin from your Jenkins installation, then you have to manually hunt down all of its dependencies and make sure that no other plugins depended on them to figure out if they could be removed, which can be a pretty tedious task. And also it means that in general, the plugins.yaml file can be quite large because there's lots of dependencies and transient dependencies that need to be accounted for. So at my company, we have a way of working around this and it's not great. It would be definitely desired if the plugin installation manager could generate a lock file on its own. The way that we do it currently is we have a file that we call plugins-in.yaml and it lists the specific plugins that we actually care about. I can screen share and show you what these files do. I'm just going to share a specific window if that's okay because I've fluttered desktop at the moment. But you should see my VS Code window, right? So we have an Ansible Playbook, which I'll come back to in a moment, but here's what our plugins.in file looks like. So it is a YAML file that is valid and can be understood by JCASC when it starts out. And that ultimately, the goal of our Ansible Playbook is to expand that into a file that looks like this. So this contains all of the plugins, all the dependencies. You can see, for example, we want blue ocean, but we don't specify a specific version and then that gets expanded to all of the various blue ocean plugins and their dependencies and so on. So when we want to add or remove a plugin from our Jenkins installation, we only do it in this file. When we want to update our plugins, we run this Ansible Playbook, which generates the big one. And the Ansible Playbook, I'm not going to walk you through all the lines because it's not very interesting, but the only really relevant parts are, we basically create a Docker container with Jenkins in it and we tell it to use that incoming YAML file, the short one, as its plugin file. We basically have a limited version of our provisioning playbooks and roles here too. So we have like a full Jenkins version that starts out. Then when Jenkins finishes starting up, we literally query the plugin manager's API to get the JSON file, and then we munch the data around and then we generate the other YAML file. So yeah, as mentioned, it's a little hacky, but it gets the job done. I mean, we do end up with a list that's pretty canonical and it's also very reliable in the sense that we know that we can trust the dependencies and the plugins that were generated because it was Jenkins that kind of figured it out when it had to download all the transient dependencies during startup. Yeah, I get it, sorry, go ahead. The desire is to give the plugin manager tool basically a command line option where you could feed it via a abbreviated file and then it would spit out the long file with all the plugins in their versions. I'm happy to pick up the torch and implement this. I'm not really sure how and I'm not really sure where to start looking and what the next steps are. So I was hoping to get some advice and guidance on that in this meeting kind of production. Yeah, I don't know if others will show up and say, I can help with that. I'd be delighted to give you a hand with that. I'm not maybe the most skilled one to do so, but I'd be happy to add it. I think that's a great tool. It remembers me of last year, Google Summer of Code where it's related to the tutorials I talked earlier about because for the tutorials, we are using Docker and Docker Compose. And to keep it up to date, we have a GitHub action where we start up a whole Jenkins instance with Docker Compose up and then we ask it to update the list of plugins. We have a definitive list of plugins, but we ask Jenkins, could you please update them? And then we ask, via Jackask, if I remember well, to output a new list of plugins because there have been some updates. And then we use that and create a pull request that automatically tries to change the list of plugins and it will be the next input for the next GitHub action, whatever. But yes, we already have something that takes a Jenkins, a plugins, but YAML has an input file and gets an updated one. And at the very beginning, we were only using, like your technique, we only listed the plugins we were really interested in and started with a vanilla instance of Jenkins. And then we tried to keep them up to date. But in the end, we had troubles because there were some invisible plugins that had to be updated also because sometimes there is some cascading dependencies and that was frankly a pain in the neck. So that's why we chose to take the whole list of a vanilla first install Jenkins and then only add to it the plugins we were interested in and then deal with the whole thing. But it looks more or less like your prototype, but yeah, that's cool. So it looks like more or less. I'd like to have something without the use of Docker if possible, but if that's not possible, then yeah, we'll see. Same here. I think for me, the biggest question about implementation is basically where does the code live that is kind of resolving all of the plugin dependencies and figuring out, okay, if I have this plugin and it depends on, let's say, Snake YAML, then I need to go get that one and kind of figuring out all of that tree. Because I kind of am under the impression that that code does not currently exist in the plugin tool. It lives probably somewhere in Jenkins, I would have to guess. And I'm not really sure if it could be brought out of there, refactored to a library, I'll be pasted. I'm not really sure what the best approach is for that. I don't know. So where do you think the best place to discuss that would be on community.jankins.io? I'm really not sure. I was recommended to come to the platform SIG because they told me I was told that that would be a good starting point of where to discuss it, but... It is. It would have been even better if Mark would have made it today. But that's okay. He's currently traveling for work. Yep, I'm also trying to... Go ahead. Oh, sorry, I was just gonna suggest I can try to arrange another follow-up discussion with Mark and any other interested parties if that would be useful. And I don't know if you saw the presentation from Oleg Nenachev in the latest Jenkins Contributors Summit, but he was talking about Jenkins Runner. I think that's the correct name. And it's... Yeah, you got the name right. I'm wondering if we could use that to do that kind of work also, not at all. Anyhow, I now understand what you were looking for. I think that totally makes sense and would be a great new feature for Jenkins. Yep. Would others have comments or questions about that? Okay, take that for a know. Thank you anyway. So yes, that was the good place to start the discussion, I guess. And I'd like to create a subject in community.jnkin.io nonetheless. And if ever we manage to do another meeting about that, a specific one, not especially a Jenkins platform meeting. But yeah, feel free to propose via a Gitter or within the community Jenkins.io post I'll create later on. And I don't think Mark will be available this week because of work and maybe not the next week. And maybe even the week after, I'm not so sure it will be available. So maybe that will just be for two of us, but we could start something and then Mark will comment when he comes back. Okay, with you? Yeah, so Akash noted in the chat that there was a PR that was open that tried to achieve this. It's actually not that old. It's from December of last year. And it seems to be kind of stuck in review though. Oh, okay. Thanks a lot, Akash. Thanks, I was unaware of this. I should have checked the list of PRs before. Yeah, would you mind, Akash, to write down the link to the PR so we can reference it into the meeting notes? I can actually drop it in the chat because I have. Thank you. Yeah. Cool. Okay. No. No, I failed. Okay, I will stop basing with that and see what I can do later on to correct it. Okay, let's have a look at this one. Oh, yes, from last December. Okay. Okay, so you still need some reviews about that. Got it. Okay, because for the time being, what you proposed, Nick, and what I was thinking of, it was outside of the tool itself. So we have to do it from the inside to be clear. Yeah, a solution inside the tool would definitely be preferred. So I guess the question would be, Akash, do you need any help with this PR, like either testing it? I mean, at the moment, it looks like it's just waiting for a review, but I mean, it's been reviewed by someone who I'm not sure if this person is a contributor or not. So I guess the question is, what are the next steps to try to get this merged? I'm still need to add test cases. So I'll try to add test cases and let you know. Okay. Yeah, if you need any help with this, please reach out to me, I'd be happy to assist. Sure, sure. Thanks, thanks. Thank you. So Nick, what is your GitHub handle if Akash wants to get in touch? It's nre-able10. I'll write it in the... Yeah. Sorry. Thank you so much. Okay. And I use the same handle on Gitter where you couldn't find me there as well. So that said, I guess that removes the need to write a proposal document or anything of the sort. You're right. The easiest solution is to just try to help Akash to get this merged. Cool. Thanks a lot, folks. Anything else before we wrap it up? No, cool. So I subscribe to the PR and see what we can do all together. Thanks a lot. We should see each other if you want to come. Two weeks from now, same place and same time. The video should be available from 24 to 48 hours for people not having been able to join. So see you two weeks from now. Thanks a lot. Bye-bye. Bye-bye. Thanks. Bye.