 Welcome to the platform special interest group. It's the 9th of April, 2021. Agenda item review proposed review the open action items. We had a discussion on Java 11 as default in all our images with Alex not here I'd like to talk to that one, so that we we've continued the discussion. And we've got pending changes to docker images that need some further discussion I think, securing the delivery pipeline, Gareth I think this is one where some question and answer discussion with you on your current experiences and would be a big help. And then security scanning just a status report anything else that needs to go on the agenda. Okay. All right, so I've got the action I'm still to do the Docker operating system. Yep, there is a discussion right now testing the idea and I like that. There's a PR where a user has proposed an arch image so an arch Linux image and answered Alex's question would you be willing to maintain it with yes I'm willing to maintain it. So that one needs more evaluation, and then we need to decide how we, how we put that person as a code owner over over that particular thing, etc. Plug and installation manager. Gareth and I were just discussing there are some additional enhancements there and this is becoming more and more widely used its standard documentation. It really does belong in the documentation there are so many good things we can do with plug and installation manager tool. Okay we had multi arch CI for s390 and power PC, and we've got arm 64 already running. No status that I've got there. And I've still got the roadmap image roadmap changes responsibility. And then was Java 11 in our default images. So this one there is continuing discussion should we consider doing a Jenkins three release in September make a major change. The discussion will continue happening in the in the mailing lists. And at that point the idea was should we make Java 11 the standard everywhere or even before that. The default everywhere and if you want Java 8 it takes a little more work. I suppose they did one of the issues is around the labels on the docker images. Because you'll be changing the, you know, the one that's just called LTS will jump from Java 11 or two. Exactly. Right. And, and the way we handled that the last time was we just announced, we're, we're changing from Debian stretch to Buster, you know from Debian nine to 10. We announced as a blog post and the contents inside the image changed. It seems to have actually worked out okay, but we would do the same kind of thing where we would just use a blog post announcement hey, the base Java version that's running inside this is switching from eight to 11. So I think this would have a lot more impact than probably switching that. Now I'm interested tell me more about what are some of the areas where you would expect impact. So there was, there was conversations with our like around running agents and running controllers with different versions and how it's not it's not a recommended thing. So I think that that would, it would be a good cause. I suppose it could cause issues but I suppose as long as there is a JDK eight variants that people can switch back to. Yeah, that's probably okay. I know that it's with a switch to JDK 11 automatically in the home chart. So if you upgrade to the latest version of home chart you'll get JDK 11 already. Oh, that's already gone in. Oh, that's good. Tim did about a week ago. I think it was the, I think that was the three dot three zero release. I think. That's great because that says we've got more and more people who will be using and those people tend to be our leading edge people anyway if you're using the helm chart. You're, you're based on very modern code. Nice. Okay. Yeah. And that there was no, no, you haven't heard any uproar any noise any loud shouting about hey you broke me. No more than usual. That's pretty good. That's encouraging. That's really great. Yeah, I'll just check out like see if there's any issues on the home chart report but I haven't. I haven't seen anything. Yeah, no, no, not, not that I can tell. I know we're in the past. That's fine. I mean, it's not these are the house because you're kind of recommended to create your own image anyway. You may well find that people are doing that. Ah, right. Okay. So they if, if they're using, but if they're using, oh, if they're using their own image, then they have they've modified the helm chart then to or parameterize the helm chart to use their image name. Yeah, I mean the helm charts already parameterized so you just you just supply you just like a new tag in your values. I will pick up the new. Your customer customer image. Okay. All right. Anything else on Java 11 in as default. Are there places as I'm thinking about other places we could add Java 11 as default already we've done it in the documentation already we've, but for instance, I wonder if we should consider changing the. If I remember right the operating system install packages already take whatever Java you have. So, so they, they don't mandate a particular Java, but we could guide users and say, Hey, you should install Java 11, rather than Java eight on your Debian or your Ubuntu or your Santos or red hat. Yeah. And let me make a note of that mark to update docs to recommend. Java 11, even on our on OS OS platforms. Yeah, good. Okay. All right, anything else there. Okay, so multiple Docker changes. These have been somewhat on hold for me as I've had to focus on other things I think the most interesting one is this replacement of install plugins.sh with plugin installation manager accompanied by documentation, better documentation to support it. And it would be a good thing to merge about the same time, or when we provide the new documentation. So anything else that I that you're aware of on any of those topics. No, I know that Damian has been working on a plugin library to allow easier building of like monorepo style Docker images, which which is one of the things that was kind of holding up a lot of these. I think it's the non root user part. There's been a lot of changes. So I think because because it was actually, we want it to you want to have all the features of the plugin library but the plugin library assumes one Docker file in the root. Every part of it's bagging and everything about actually what we want to do is build multiple images from the same repository. So he's, he's been experimenting with ways that we can get it to do that. Excellent. Okay, good. So securing the Jenkins delivery pipeline, Gareth, this is the one share with us. Some of the things you're, you're seeing as you're experimenting with JEP 229. Yes, it's all in all it's been, it's a much nicer. And what we've currently had or what we've previously had. And especially for plugins that I used to maintain and like I don't know where my credentials or information to release it from my local machine and having a set up is something that I always forget about. So having like a single place where you can do it automatically on a interesting commit is really useful. It's really handy. Some of the kind of enhancements that we've been looking at on some plugins are around, rather than using the generated building number which you've got an example of that 820.bap something or other, because that's not semantic. It's not a semantic version is to use Jx release version to determine the next semantic version for you automatically. And we've had some good success with that. And it now Jx release version generates. It's the next version based on current version. So, so it's it's doing and based on contents of the log tell, tell share more detail may not have heard before of how this thing works and it would help for for the recording etc. I mean, yeah, sure. So it's it's it tries to determine the latest tag that's already there. And it uses that as a starting point. Well, then look at the commits that have been added since that tag and where you currently at. And it will then calculate what version bump should be based on the conventional commits. Sort of stuff. So it is a Jx plugin is a garland binary. So you need to run it in a container or bundle it in somehow. So it's, it's, you know, it's not quite Jenkins native yet. It's pretty good. So, and it was increment the major version if it's a breaking change increment the minor version, if it's a feature. Okay, and increment the patch version. Otherwise. And so the example there for my benefit is one dot X dot Y becomes two dot zero zero. And then this one it'd be one dot one dot X becomes one dot two dot zero. And one dot one dot one becomes one dot one dot two. Yep. And just using that, that sort of reasoning scheme means that when you're looking at plugins in either in the plugin installation manager or the manage Jenkins interface, you can actually see what the changes are, you get straight away and you can say I'm fairly close to this plugin rather than, I don't know, build a 20 jumping to build a 24 with a random chart the end I don't know what I don't know what that is. Yeah, it lets me in for the distance from an upgrade is covering right so if, if previously it was one dot X and now it's two I know oh that's a bigger distance than one dot one dot one going to one dot right. Excellent. Good. Thank you. Any any insights there you want to share I assume we keep talking about it and share more. I assume eventually we do it want to blog post on it or a discussion in some location about. Okay, here's this additional refinement to, to JEP 229 that will allow us to use semantic versioning. Thanks to, and you, you, you described it it was convinced. I mean, I think we need I think we probably need project 229 we probably need more of a guide on how you can upgrade to that for your existing plugins. Like we and try and explain the options that are available. I think, I think that the, the JEP proposed there's a lot of information on the JEP proposal. But I think it means that people will miss stuff, and they weren't quite find out what they need to know. Right. Okay. Which, which, I mean we've done developer online meetups before for these kinds of things this might be a great one to do a developer online meetup to say look, here's how you can improve your development process as a plugin developer. Life gets simpler if you'll do this. And here is this tool that will help you do that. Yeah, we probably need like a proper, proper pages on the link from the, the plugin developer part of Jenkins.io. Right. So that it can be searched and index with with a link to the recording of the online meetup or something like that. That would be, that would be really handy. Right. Okay, good. Excellent. Anything else you wanted to share in on that. No, that's good. Okay. Last topic was just the security scanning of our Jenkins images, and actually not just images and binaries so Oleg's working with and discussing with the Linux foundation on improved possible improvements to the scanning interface that they provide. They provide a scanning service. There are some gaps in it. And he's working to see what we can do help those gaps. Any other topics before we close our meeting today. All right, thanks everybody. We will meet again in two weeks. Cheers.