 Okay, did I get. Welcome to the Jenkins platform special interest group meeting it's the 7th of May 2021 reminder that we abide by the Jenkins contributor code of conduct. So, thanks very much for being here. Topics that I had on the list open action items, securing the Jenkins delivery pipeline, Java 11 as default in all our images. Those docker changes. Security scanning status. Anything else that we should add to the agenda Alex or Gareth anything that you have that needs to be included. Nothing for me. Okay, all right. So, so on the action items topic then I've still got this one, the jet process really is becoming easier and easier intentionally so this is there's no excuse I just need to get it done. We've got a proposal on the second action item proposed to include to provide plugin installation manager docs as part of the Jenkins on Kubernetes documentation project and you can see it's RV. Sudakar is working on it. With the doc sig. So glad to glad to see that it's I think second or third. See the see the proposed outline in the docs mailing list. So, some questions are happening there and one of the one of the items is that that exact topic of plugin installation manager let's document how to use it well inside of our docker images and thus inside Kubernetes. So, the finalization and multi arch is is arm 64 as 390 still interesting not yet happened. And I have opened the PR for changes from the contributor summit so at least one item is done on this list. The next piece was securing the Jenkins delivery pipeline. So, Gareth and I have worked on a elastic access plug in has switched to use semantic version automatic semantic versioning with continuous delivery. Gareth, I saw a comment from Jesse Glick expressing concern about the technique. Have you got any insights on on Jesse's Jesse's concerns or is it something I should take up with him separately. Actually, I thought his concern was on the other versioning scheme. Oh, oh, it was, it was hard to read because it's a slack thread, but it's difficult to read but I took it as, when I put the example is a 27 dots and random char. I think his concern was with that is that's going to work with me from versioning semantics. All right, so to, so I just need to let me take the action I'm to discuss with him to confirm that the the technique we're using an elastic access is not going to be a problem for Maven because as far as I understood what we did there looks exactly like semantic versioning right it's exactly three components and applies the semantics of okay patches increment the right most component features increment the middle and breaking changes increment the left. So that that versioning tool to Jack's release version is used throughout Jack's and most of the libraries that it creates so it has no problems being no deciding the version of component that's used as an dependency somewhere. That should be fine. Okay, super. All right, so that for me was was the experience is great. I haven't yet released off of a branch. So there's still some work to be done there on elastic access to be sure that it works but it felt good when when Gareth and I did it it just seemed to work. We've also released the tech on client plugin today with the same approach. So that switched over to use the, we're already releasing with the jet 229 but we had we were kind of munging a version together. Because we didn't want to go with the one dot zero zero yet, but today we switched to the one dot zero zero and now it's using the same approach as elastic access. Cool. Okay, so so now we've got two reference implementations that we can use to decide. This is this is a test great. Where do I look for the, what's needed to implement that is that here let's let me like to do that on token macro. Yeah, has token macro already switched to use continuous delivery. Yes, the other way. Yes, I'm not sure you want to go. I haven't released anything yet. Oh you haven't. Okay, all right well so then, then let me put a link here. GitHub.com. Yeah, report version dot channel. No, actually, I think it's workflow GitHub action so let's, and maybe. I've just popped, popped one in the chat, which should be pretty much identical to what you have. Perfect. All right, so this one. This is the tech on client one good. All right, so I'm just put that link here. And then the elastic access one I can put because the same thing should work for elastic access right that same path. There it is. It does. Okay. All right, cool. Yeah, so at least, at least it's a I think it's worth. Yeah, the report version pipeline we added as a sort of a method of debugging what Jax release version was going to determine as the next version. Gotcha. Okay, because because it can be run on workflow dispatch you can select a branch to run it against so it's just it's just a useful debug tool, it's prints out to see what the version is quite handy. So and truly this has been a fun experiment so when I click deploy, let's see was it deploy. Yeah, this will now tell me the next version number it would use. Oops, no I have to click it correctly don't I report version I say run workflow on master. Yeah. And now I get the output will tell me what version number it would have done the increment to good. Okay. All right. So token macro. All right, now I'm still, I'm still not fully personally through the transition yet to using some using can what oh there it's conventional commits is is still a learning curve for me right I haven't yet train myself to always use a conventional kind of text marker text and and that's just needs practice. Anything else on securing the Jenkins delivery pipeline. I mean, as something in the future that you could do. You could determine the next version number base on the release draft a conflict. It's almost the release after conflict but with the release draft a content. If we say it's a major release or breaking change we would use that to bump the next version. So it would be a case of getting hold of the doing the API call to get the release stuff and then analyzing the text in the same way that the interesting check does. I mean, looking basically at the contents of this next thing. Yeah, so you're so you're like if you have a new features and improvements for instance, that would be that's a feature. You know that's a minor release there. If it comes up as major changes then we know to bump it from that. So if you, if you don't want to use the conventional commits as a as a process or as a way of determining this stuff that may be an easy way of doing it. Right. But and there it would need either extensions to JX release version or something other than JX release version to decide the version number is that how that would work. I think other than JX release version, but I think I mean you could. It wouldn't be too difficult to do because I think the difficulty would be like, if you have to make a multiple get had calls, have API calls to be able to determine that then it's going to be difficult. And you probably need to write something to be able to do that handle that. You should be able to do it. You've got there's already the logic there in the, in the current deal have action to get that content and pull it back. So, and you've got the logic to interpret that they're ready for you so it shouldn't be too bad to make that decision about. Oh, right. Because we're already exactly as you said we're already reading the contents of this thing inside the action. Yeah. Right. Good. Okay, thank you. Right. Good. So you read that read, use and use the release drafter content. It's really use the release drafter content we're already reading to decide the level to increment. Right patch. Minor or major. Yeah, that could be an alternative to conventional commits if that's something that people don't want to use for instance. Right, right. Good, good insight that is that is an alternative. Thanks. Okay. Anything else on securing the delivery pipeline. Okay, next topic then was Java 11 as default in all our images so the conversations. We have moved between. Drop Java eight. The most aggressive maintain Java eight for a limited period. And yeah, that I think was the two comments. Anything the two of you want to guide there in terms of where we should go with that I think I'm prone to this maintain Java eight for a limited period. I think we should go with that because, because it's, we don't have enough Java 11 adoption yet in the in the Jenkins install base that I can see. Yeah, I think we probably have to maintain Java eight for a period of time. Based on the feedback that was on the main list about Java 11, and that was just for that wasn't even for the Docker images necessarily that was just in general for updating the source level to 11. But it seems like there's still a lot of people use Java eight so we can't really just drop it. Right. Okay, although for Docker containers, to me it seems kind of weird that we don't deliver that much. Oh, I see you know what I mean is, we could, we could could drop Java eight from Docker containers that's not stopping the project from using Java eight, but just don't deliver any more Java eight in the Docker containers. So the platforms that we deliver Docker containers for support Java 11, and even better, actually then Java eight on like S390 X and so forth. Right. So, yeah, that's, that's my take. Okay, thank you so I'll, I'll bring that comment to the to the discussion and I think Oleg had noted time to submit a gap. Right. So let me put one action item for me that that I need to submit a gap for Mark open a gap for Java 11 as the default as the standard Docker image basis. Okay, good. Right now. Back up. Okay, so anything else on Java 11. Okay, Docker changes. So multi arch builds, no progress. Alex you had noted arm 64 improvements, anything you want to report there or still still sort of holding. I'm still holding right now. I do want to get back to this but I just haven't a chance yet. No problem. That's great. Yeah, and, and this one, more and more people are using plugin install manager. I think this one is a is a good one to do as we publish the documentation for plugin install manager that's when we merge that and declare. Hey, we've changed to use this new way of doing it. The question is, should we ask Sudakar to sequence documentation of plugin installation manager first, so that we can use it sooner. Comments more docs is always good. Okay, yeah, so that's great. All right. So user on agent Docker images. I'm not sure I think that's not yet been merged so or or Gareth is this one that the to change was made it's definitely not been merged is this one that the change was made in the infra images so that the infra images are not using root. So we've worked around it in infra that we're actually not executing as rude anymore. Yeah, possibly. So it's only on the it's only on the agent side. Right. I think this was because this was all part of that. It's quite a large change change set that they mean was looking at. And I think what he wanted to do was look at a much better or more efficient way of building these images. I think that was the, the idea. So he's looking at the change the pipeline library to support multiple different Docker builds and that kind of stuff from a single repo. Got it. Investigating back at the safe, you can have almost like better inheritance. It's not an American's in the container but at least in the logic that we use so we don't have to duplicate it everywhere. All right, thank you. And announcing those changes we're not ready to merge them nothing to announce yet security scanning so Oleg is has made further progress with Linux foundation security and sneak, and is is actively doing a co-working thing with them to help adapt sneak to better understand or adapt what we need in sneak so that it will better understand Jenkins use of Maven, and not incorrectly flag things as a dependency that are that are included as a dependency and by the Maven HP bar our HPI process. There's, there's work going on there. So, very glad for the progress always making he regularly reports on that and the governance meeting and elsewhere. Code QL scanning. I'm, I think this is where we're now in discussions of how do we deploy it more broadly and hosting requests so, oops. So, Alex in terms of hosting requests I assume it's still being used there. Is that correct. The code QL. Yes. Yeah, it's not like a. Yeah, it's still just a local copy it's not a. Oh, right so this is not a systematic review. This is okay. So, so as you are stepping away from hosting requests, and we're getting more people added to the hosting team will they likely use this local as well, or is there something different. That's a Daniel says we he and Oleg and I, we got on that meeting yesterday. No one else showed up so just kind of chatted about some things. And that was one of the things he said was he was happy to give people access that we're doing the hosting requests processing so. Okay, good. I don't know if he's going to do like a blanket everybody who you know starts doing it right away, but I think, you know, at some, you know, as people are vetted or whatever it will be access will be given. Right, and that makes sense. Very good. Any other topics we should discuss today. Okay, Alex, Gareth, thank you very much. I'll post the recording after probably later today or within a few days. Awesome. Thanks, Mark. Thanks.