 Welcome everyone. This is the platform special interest group. It's the 23rd of April 2021. Remember we live by the Jenkins code of conduct as we're in meetings, be good to each other. So topics I had on the agenda included open action items. Java 11 as default in all our images. And let's see we've typically talked coordinating proposed Docker changes would love to have further conversation there. Securing the delivery pipeline, Gareth would you be okay if I put that one earlier in the agenda so that we could absolutely be sure we get to it. Okay. And security scanning I can give a status report there on, but it's just a status report. Alex or Aditya. Are there any topics that you would like to add. None from Lacey. No none for me. Okay, super. All right. So action action item review there. Oh, Gareth I assume none from you other than the one that you're already on. Great. Okay. The JEP I still have not opened it I can the draft is there and encourage people to give feedback on it. The concept seems to be holding. And Alex mentioned it in, in a PR review to a particular person, and I was delighted that that person said yes they were interested in being a code owner. So it was sounded very promising. The plugin installation manager thing is just going to go into the docs. It is becoming more and more popular, more and more important, and it keeps getting used more and more widely in more and more ways Jenkins infras using it now, etc. No progress from Jim Crowley on the multi arch work. Though I continue to use arm 64 and lots of ways, and I'm very impressed with it. And I still have a PR that I need to open for roadmap. Anything else on the action items. Okay, so Gareth, securing the Jenkins delivery pipeline particularly JEP 229 and the refinements do you want to take a minute and share with us what what you're learning and what you've, what progress. Yeah, sure. So the particular piece that I've been looking at is, yes, if there is, I suppose it's the refinements or enhancements around 229 to allow automatic semantic versioning to trigger with JX release version. So what we have is JX release version is available as a GitHub action that can be run to determine the next version based on your eventual commits history. And then we set the version into the plugin before updating of code applying and then update the tag to point to the right place. It seems to be a nice kind of replaceable piece inside that JEP 229. So it seems to work quite nicely. The next step that we're hoping to do is to try this out with a multi branch plugin. I don't mean the multi branch pipeline piece I mean a sort of a plugin that needs to maintain multiple branches at the same time. Just like box writing in there. I think that's about it. So the intent here for Gareth and for me he and I are going to work together on this one is we intend next week to take one specific plugin in this case, the elastic access plugin. I know you're all deeply committed users of the elastic access plus plugin and you're one of the 300 users in the world who use it. And since you're probably not. I happen to maintain it, and it's a convenient place to do these kind of experiments with relatively low damage potential. I'm not going to hurt anybody it's not like if I did this to the get plugin and suddenly people became outraged. The elastic access plugin will release two versions, our hope is to release two versions or more next week. As a test, and it will have switched to continuous delivery. Using JEP 229 with these extensions that Gareth has performed and and automatic semantic versioning. You're not any yellow, yellow ops mark. I actually am in yellow ops and this is the clear evidence I'm in yellow ops right because I'm going to you all you do only live once but you don't only live once with the get plugin right you only live once with with small things first. So I really do envision that the day will come when the get plugin will use this technique because it looks so promising to me in terms of keeping things clean and tidy and but but that's not the first target. Awesome it sounds really cool. Yeah, well and, and part of the experiment here right I transitioned the platform labor to JEP 229. And it was a good experiment and it's been successful, but I find it hard to read the version numbers and I and I've heard others in the community comment that they find the version numbers hard to hard to use. So this is an attempt to refine that and see, could we use more commonly use version numbers and still have fully automatic releases. Excellent. All right. I switched token macro over to JEP 229 I haven't done there hasn't been any PRs or anything for release so I'm hoping this stuff comes in pretty quick so I can use it there that'd be really nice. Oh, right because you see I can't switch platform labor because once I've delivered a release there's no going back, but you haven't yet delivered a release. So this could potentially help token macro. Cool. Okay, good. So keep Alex informed of progress, because again token macro is one of those that's only installed in 260,000 Jenkins installations worldwide right so only only every Jenkins installation out there has token macro. Excellent. All right. Would would love to switch after after first tests after successful tests. Very good. Very, very good. Thank you. Glad you were here today Alex that's really wonderful. Anything else on securing the delivery pipeline. Okay. The next topic was Java Java 11 is default in all our images. So the crucial question for me there is the Jenkins slash Jenkins colon LTS and docker image today is delivering is delivering Java eight, but the day will come. So the request had been made previously by Daniel Beck and others please do those kind of changes on on out on major LTS dot ones, and we've already done the baseline selection I don't think we're going to fit for June. So the rough, rough idea, make this transition in September. In the September LTS. I think that we can use that that aligns with Java 17s targeted release date. It doesn't matter that it's aligned but it's, maybe I should say it this way near the Java 17 release. Any objections there on that concept. I think it'll be it would be discussed at the contributor summit. I can raise a mark to raise an email to start the discussion. I suspect there may be a request raise a Jeff. And I'm not sure if if that will be needed or not but I think it's worth the discussion question mark guidance there Alex or Gareth in terms of process Alex I think you've got the most experience process wise for those what's the what's the best way to success. So everything that sounds good. It's a big. I don't think it's a huge change, just because we've been running on Java 11 for so long now that I think it's extremely stable but obviously some people probably not like it, just like everything. I think it's fine if we do some announcements ahead of time and so forth and just let people know that that's coming that, you know, in September timeframe. If they pull the LTS image it's going to be Java 11 going forward. I don't know if we even stop publishing the Java eight images or stop updating that's a maybe a second part of the discussion. Well so this one, if we replace Jenkins Jenkins colon LTS that would mean we stop that one would no longer be Java eight, and I would not create new images that are dedicated to Java eight at least not for my personal taste so. Okay. But that's a good topic for transition described in the jab. I'm not sure if we were planning on doing like changing the published location of the Java eight images to be like JDK eight like we have for JDK 11 right now. But yeah, sounds like we don't need to. Well, well I was, I'm hesitant to add any more image labels to track, then absolutely necessary just out of fundamental laziness. Sounds good. Okay, and then so that that for me. All right, so that that feels like okay. Great. All right. Anything else on Java 11 as default. Okay, next topic then propose Docker changes and we've got several there. So, I am feeling completely behind on Docker image maintenance, our others can others give me a hint on how we're doing there. So you've made significant progress and using Docker images more consistently in Jenkins infra. I don't think though that that's touched the Docker delivery that we're doing the image delivery that we're doing to create the base images, am I correct there that your work has been around. We've been looking at better ways of those customizing the controller image to contain the plugins. So they're not downloaded each time on on pod restart. That's the main reason. And so, and that's, that's really in the infra usage and getting more and more of our infra towards configuration is code with with precisely specified definition of of that Jenkins instance including its plugins and versions. There's a bit of an issue with the current helm chart in that, in the kind of default way that you add plugins to it, the downloaded on startup, they do get. There is a way of caching them onto a system volume, but there is also a possibility that when a pod restart, it's going to download a newer image, a newer version of a plugin that you're not expecting. Oh, and, and you may run into possible issues because of that. We had one with the EC2 plugin where it was a minor release, but actually it was removing configuration and the pod was going to start properly. So there are, it depends how, yeah, yeah, it's not ideal, but what we do is we regenerate a plugin's text file inside the controller image and basically download those with the plugin installation manager. Those exact versions. And then that becomes the image that is there. Excellent. Thank you. Okay, very good. Alex, I'm assuming that, or is there anything that you wanted to share here Alex in terms of any things that we need to be aware of. I wanted that PR for the internals of install plugins. So you're referring to just in general on Docker changes so install plugins certainly that one's hasn't been merged yet, and I think we'll need to announce when we do. And I, I think I still need more tests, but anything in general here or that specifically. So my kind of next thing that I want to look at is getting all the multi arc stuff in, because I would really like to use official like arm 64 and images and so forth so I'm going to probably be looking at Jim probably stuff and see if I can move it along. Okay, integrated for the multi arc stuff. All right, and that that I would love to hear that because I would love to be able to use on the arm 64 stuff that I'm doing. That would be a great help. Thank you. I'm probably going to set up a local Jenkins instance and connected to those like that's 390 X and RPC agents like you do so I may be pinging you first up for for ideas and so forth because I know you have an awesome setup with for your testing. Yeah, I'm happy to happy to assist there absolutely just reach out because I found them to be very reliable. Convenient to use and yeah it lets me fake CI Jenkins that IO before I before I go live on CI Jenkins that IO. All right, any other topics there on proposed Docker changes. This topic is just a status report on security scanning of binaries and images. So, Oleg is is leading an effort now is discussing with LFX security LFX security. LFX being the Linux Foundation, they have a project called LFX security that offers scanning of open source projects with what is at its back end a sneak instance so. And right now, the noise level because sneak doesn't understand Jenkins dependencies. The noise level is unacceptably high he's working with trying to see are there ways we could help that or improve that or work with sneak directly to to get that better. It's it's still an ongoing ongoing investigation nothing to announce nothing to share. Now in terms of there is the code QL work that's not really images and binaries. In terms of source code. That prototype is available and or is is running on some Jenkins repositories. Thanks to Daniel Beck. If you're interested in getting more involved with that you could reach out to Daniel to join up with it. Well, Alex in the hosting, when you process hosting requests were you using code QL as part of that or not yet. So Daniel kind of hooked me up with a like a local version of the code QL stuff that I that I run locally. It would be great to make it part of the IRC box, but at the same time it does require a little bit of human checking, because sometimes that there are false positives and things like that so it's. It's awesome because it picks up a lot of the things that I normally have to look for in the hosting process for security things. Good. Okay, so just the fact that you've been using a local copy is already encouraging that that says, as we as we're transitioning away from putting the so much burden on you for hosting requests that others are picking it up. They'll likely need to know how you do that and what the techniques are very good. Excellent. Thank you. Anything else on that topic. I don't remember how itself has some image checking. I don't know what it does specifically. But that might be something we look at to. Okay, good. Again I don't know if it'll know about the Jenkins dependencies and stuff like that so I don't know how useful that would be necessarily but that that one at least would let us that has the I assume what they're doing is something like on chore does or or others where they look for vulnerabilities in the base operating system image in addition to looking for known CVE is on the product that's on it so in this case looking for known vulnerabilities because we failed to update an alpine image or something like that. Right. Okay. Good. Anything else there. Okay, I think we've covered our topics. Any other topics we need to discuss. All right, let's call this meeting done. Thanks very much. I'll get the recording uploaded probably later today or possibly early next week. Thanks everybody.