 Okay, welcome to the Jenkins platform special interest group. It's the 26th of March. Great to be here. So topics for the agenda I had action items will defer the open container labeling till Gareth's available to attend I wanted to give a status update on she code Africa just so that people are aware. And then we had coordinating proposed docker changes. And let's see topic for me was securing the pipeline the delivery pipeline, just a brief status there. And this one we had last time security scanning of images with no no real change for me. Figured we probably ought to review it just to be sure it stays on our list. Alex, any topics you want to be sure we touch. No, I don't think so. Something for a future agenda maybe is moving to Java 11 as default for all images. Oh, very good topic. Yes, possibly deprecating the Java eight at some point. Java 11 as default in all our images. Windows images right now. So, yeah, let's, I think let's let's put it in there. Let's be sure we've got windows now windows docker now. We've got install instructions now. And, and it's getting more and more right I'm not sure even the Debian, for instance will with bullseye naturally include Java eight at all so so it's more and more the default Java is 11. Yeah, good. Okay. All right. I'll just bring it up when we actually get to the topic I guess sorry. Oh that's great yeah so let's, let's go through the topics that any other topics you want to add. Okay, well then what I do say is let's put that one right at the top of the heap, and assure that we get to it so action items. I've still got the jet to do and the plugin installation manager increases in popularity. It's being more and more used all the time. So I think we're getting closer and closer to just merging your pull request to replace install plugins.sh internal implementation with plugin installation manager. Cool, that would be great I need to double check I think I resolved the conflicts but I will double check that. Ah, good. Okay. Yeah, and I, I haven't done specific testing that I think Gareth had, and I'm seeing lots of activity in bug reports where they're using plugin installation manager to replicate problems. So, it's, it's more and more the, the tool of choice. I would like to, at some point, use like an environment file or something that specifies the version of certain things. So we don't have to go around and update 20 Docker file. That's something I'll look at in the future. Yeah, and for me, I don't mind it because it's it's actually a pretty easy said command to do a bulk replace so don't, don't, don't feel obligated that's great. If, if it happens that's wonderful in my case I just do a get LS files pipe to said minus I and so it's it's actually quite straightforward. I know, if there are other things that we eventually have that have like version we have to update all of the places kind of annoying like they're specific cases in the Docker agent where you have to go around and update several places for the Well, and that's so that lobbies for more general purpose tool. Good, good suggestion. The, there is a tool, Olivia vermin has a tool called update CLI that he uses to do these kind of sort of sophisticated updates it's a piece of go lang code that he uses for various update checks. And it's a super advanced depend about that knows very precise things. So, it might be worth a discussion with him to say hey, could we extend that to also maintain these version numbers they're right. Cool. Yeah, that'd be great. Anything else on plugin installation manager, then we we still have a topic on multi arch improvements for Docker images, it will probably be many weeks before I'm back to that one. I haven't seen any activity from Jim on it so I'm assuming it's quiet for now. And I've still got the action item to note the PR for the roadmap changes that came out of the contributor summit. The new June concert contributor summit is being planned now, the day after the day before CD con, just out of curiosity are the, are the agents, the 390X and the PRPC agent to those tables now for you. They are they're still connected still working. And in fact, I'm using them at times for just general purpose testing and they're quite reliable. Cool. I know we had some issues for a while, so I just wanted to check on that. Yeah, and I actually installed operating system updates on the power PC and and confirm that it could reboot and it survived. I was a little scared, but it worked. Yeah, so, and the the AMD or the arm 64 agents provided by Amazon of also as far as I can tell been been behaving well when they're called. I don't think so. I don't think the packer image has been changed at all. So I think, I think we're still using the original ones that you created. I think those there's a cheaper option now that we maybe can look into. I'll look into that for the packer image. That's an interesting one. Thank you. So, next topic then was Java 11 is default in all our images so it's already that you said Alex it's already the default in Windows Docker, and in the Docker install instructions. We don't really have a concept of a default for Windows on the MSI right it uses whatever the user installed. Well, the precedent is Java 11. If they have both Java 11 and Java 8 installed it will Java 11 as the, you know, and it looks for a default JVM to show the user can always change that it will look for Java 11. Okay, so, so, and I think Tim has Tim Jacob has proposed additional default changes. And I forget where they were but I know I've seen a pull request recently from him proposing it. I think it's it's worth us continuing along that path and just planning that we need to more and more persuade our users they should be using Java 11 for their own benefit. Yeah, and especially for Docker, it seems to me that that's kind of like if you're running a Jenkins controller under Docker. You know, why would you care whether it's Java 8 or Java 11. You know what I mean, because it's not like you have to install the JDK on your host OS and stuff like that it's all running under Docker. So that's my why I think we can do it first in Docker. So even on the agent, you can still build with a different JVM or JDK, then the one that the agent is running under. So it just to me it makes sense that we could move to Java 11 as default sooner rather than later on Docker images. Yeah, well, and that's, we did it we when we did the Docker image change from from stretch to buster. We blogged it right and made the change and it doesn't seem to have been a terrible disaster right I haven't had any active hate mail or anybody saying that was a terrible awful decision you made. So, we could do the same kind of thing. And change the base image to use Java 11. Instead of Java 8. Yeah, that was what you were lobbying right is because we have a JDK 11 image now but we may want a JDK 17 image. It's that the base tag today uses Java 8 and we eventually want to switch the base tag Jenkins colon Jenkins or Jenkins slash Jenkins colon LTS to use Java 8. Correct. Yeah, that's my, that is my recommendation or suggestion or whatever you want to call it. Yeah, I think that's, that's, and certainly that's a place where we would probably want to do it. Likely want that change based on Daniel Beck's guidance earlier on an LTS.one release so to what we guess 2.9 x 2.29 x.one or something after that. There is, there is a conversation going on about when should should we consider doing a Jenkins three in September. And that might be an ideal place to say Jenkins three is is going to go Java 11. Yeah, I think that's about the time Java 17 releases as well. Yeah, I think that's all I was kind of looking at. So, Jenkins does not currently the tests will not currently function under Java 16. Some of the dependencies like power mock does not work under Java 16 right now. Okay. So there's a bug on their repo for that right now. So, I just did it tried to do a build, just to see what what things fell out and that was the major thing I found was the testing does not work correctly. Okay, well, and that's, that's a reminder that Java 17 is coming this calendar year right or is planned for this calendar year. And that is, it is intended to be a long term release everything I've said, it's indicates as a long term as an LTS Java. Okay, good. Yeah, there are other things there that we need to that need to be of concern for us as we as we think about how we make that change. So, our boundaries when we can do it are pretty narrow LTS edges. So we've got June or September as the two candidates. The number is probably good if they're talking about Jenkins 3.0. I assume that 3.0 would be a long term sport release. I would think so as well. Yeah, I think it's still in discussion but it's what you remind me is that I need to be sure when I'm in any of those other meetings that are talking about Jenkins three it's yes. And that is our chance to do, you know, for instance, our base image instead of buster should at that time be bullseye are we should be using Jenkins three we should be using Java 11 and be ready, hopefully pretty soon to support Java 17 in that time frame. Yeah, that sounds good. Good. All right. Anything else on. Yeah, it does have Java 16 images we could base things on at least we could build and not test a Jenkins war and then pull that into a Java 16 Docker image to see if it runs at all. You know, so separate from just the testing portion we could at least see if it runs. So I can do something like that. And that's that's so that wouldn't say we would take the code we currently have compiled but executed on Java 16. Is that what you're saying. Well, you can build the war file. If you just can't test it under Java 16. So what I was thinking is actually just just building without doing any test, and then creating a Docker image with JDK 16. See if it runs at all, you know, or whatever is pop up or things like that. So, so there, I was assuming you do the keep the build that we've got with Java, Java eight base build and assure that it runs with Java 16 you're going one step further let's compile it with Java 16 as a way to learn what the changes are Java 16 brings it for compiled code. I mean, I know there are some changes to the just in time compilation and things like that. So, it's possible that or sorry, there are optimizations and that's in the 16 and 17 for my understanding. It's possible that might be helpful for our workloads, but we can just take the Java eight or and run it under Java 16. I can do that too. Good okay that's that's a good those would both be. Yeah, very interesting, particularly as we're getting towards. We don't know if a Java 17 early access build has been generated yet that certainly Java 16 can perfectly reasonably can be considered a reasonable predecessor reasonable experience for what Java 17 will include with Java 17 getting more than that. That was my kind of assumption I don't think that they're producing any Docker based images with a 17 early access. That was why I was kind of starting with 16 at least. Oh, and I like that because that says we leverage all the work that adoptium is done and and just use their images because we're going to be using their images anyway that's that's wonderful. Have you seen anything on on any platform specific topics like arm 64 support focus in 16 or 17 beyond what we already had we've got great support already but is there anything additional there that we need to be aware of. I think it just it's just continued iterative improvement. Okay, those platforms are because are, you know just are more popular and becoming more popular, because they're lower power than than Intel or AMD. So I think it's just going to get more popular so they're probably just spending more time adding you know, fixing bugs, improving things is my understanding. Great. Excellent. Thank you. Anything else on Java 11. Not for me. So skipping open container labeling one minute update on she code Africa. We've been accepted to the contributon. It will start April one it's focused on pipeline examples and getting those into the plug in source code. They'll then be visible on Jenkins.io as well. Looking forward to it looks like we'll be mentoring up to nine women from Africa, who will be first time contributors to the Jenkins project. That's awesome. That's way awesome. Yeah, so that's I am, I am thrilled we may we may do more than that for right now this. That looks like about the stretch of it and I've got mentors aligned we may have to go begging specific plug in containers for a little additional help as we go through it, but we'll see. So next one was proposed Docker changes and I think the big one here is install plugins.sh. We just want to continue testing that I don't have anything to report on the others do you have anything you wanted to flag Alex. No, no, not for me. Okay. All right. And quick update on securing the Jenkins delivery pipeline, JEP 229 using plug in release delivery through on what we would call trusted infrastructure or on non developer desktops is so outside developer desktop is working and we've got some first experiments, the platform label or plug in is has implemented. In the token macro plugin. Oh, you did. Oh, very good. Okay. I don't have any PRs yet to merge to have a release done but it it publishes the incremental and has the correct version and stuff like that. So, I'm assuming when there is a PR, it will work. Excellent. Yeah, so, so I've released several versions of platform label or some kind of nonsense it was, oh this feature is documentation, but it's, it's worked. I'm, there is additional work happening there. Gareth Evans is exploring to see if there's a way that we could preserve, preserve semantic versioning and still have JEP 229 working. So one thing that I was, there is a way you can do that but you have to manually update the prefix versions, as opposed to having them auto updated. Yeah and what he's, oh go ahead. And Jesse did not recommend that so I didn't do that. And I agree wholeheartedly and what Gareth Scott is because of his past experience on Jenkins X. They were doing semantic version with versioning with automatic maintenance of the version number based on commit messages there's a there's a sort of a standard on called general commits where they you put specific text into your commit message and that is used to apply labels to the GitHub repository or to the pull request and let it decide then which kind of version number increment it needs to use. Interesting. Yeah, and it's a it's actually Google Summer of Code project idea. So, so we'll see how it works. He may implement it himself, or, or just continue the idea but it looks like I love JEP 229, but the version numbers are a little intimidating. And if we could preserve semantic versioning with still automation that's all that sounds very interesting. Yeah, I agree. Then last people kind of weird thing like filled 862. Yes, yes, you hit it exactly right it's, it's really build 8, 821 dot V. Yeah, ABCD EF a 1234 you know that that that is, oh that's that's a surprising version number I can ignore the Shaw one on the end, but that big number at the front sometimes distracts. Yeah. Anything else on securing the pipeline. Okay. Security scanning I don't have anything to report there I'm watching watching the sneak scan results. And, and the thing that I learned from talking with Oleg is that the key gap is that the Jenkins HPI packaging is not understood by by the entrepreneurs. And this was thing I didn't realize and thus it flags outdated dependencies. It flags older dependencies as issues, even if I never run that older dependency in Jenkins. And it just, it's a, it's, I don't think we're ever going to persuade sneak to understand HPI packaging. So the the moral there is keep updating our dependencies with dependable. There's no way to help depend dependable with certain things because it doesn't seem to like, it'd be really nice to depend about could manage the plugin installation manager tool, for instance, is there a way to help it. Update CLI I think is the closest thing I've seen to a helper and it's not really a helper it's a replacement in that case. But it's a good question. I don't know I'll have to ask. Very good question. Yeah, good question. Thanks Alex on security scanning. Nope. All right, I think we've covered our topics. Alex, thanks for your time. Thank you, Mark. Bye. Yeah.