 Welcome, this is Jenkins platform, Siegmeaching, September 23, 2022. And it's right today. Welcome everyone, thank you for being here, Mark. Today we have quite a long list of items to have a look at in the agenda. So we have open action item for Mark, of course. A little subject about WISC-RICS-5 and Jenkins agents, container image deprecation for the blue-ish container. Container repositive management for Jenkins agents. We have to talk about that. Of course, we also talk about Java 11 or newer for Jenkins core. Of course, Java 17 support in Jenkins and also Java 19, which has been released this week. Next week, we're gonna have DevOps world and Mark and I will be there. So we, of course, have to talk about that. And the last subject will be the supply and chain security. I want to know more about that because that's something I don't know yet. Mark would address this subject, of course. First of all, open action items, Mark, agents of CI Jenkins IO on PPC-64LE. So still the, I saw that the CI.Jenkins.IO agent actually is still running there. So that part is still functional but I still have not shared the credentials and I've got on my own setup, I've got a problem with it that I need to investigate that I'm not sure what's going on. So that will need further investigation after DevOps world. So you have your own PPC-64LE? Actually, I just use the same computer. I just have a different user account, borrow the same computer and that way I know when it's behaving or not. Okay, that's a platform I don't own yet. We'll see, some of them are difficult to have like the S390, that's something I will have with me in the office any time soon. Speaking of platform, next one is a short subject but the other day, Michael Hurt organized a giveaway to get a MQ Pro so that a small, very small SBC with a risk five, just one core, one gigabyte of RAM but it's a nice board anyhow. And believe it or not, I put an entry, say that, oh, I would like to try Jenkins agent on that and I won, so I should receive by next week, maybe at DevOps world, I will maybe get it there or when I come back so that I could with lots of quotes, you know, try along the way to get Jenkins work on that. And of course, to get Jenkins agent working on that, we have to be sure that Java works. There are some GDK available for risk five. I will take some time to evaluate if that works or not. And I also love to run a Jenkins agent with Docker. So Docker is also available, all of that is very early stage so don't expect that something will be available in the next week also, no way. Anyhow, I would be glad if we could have another platform, another architecture available for Jenkins agents. Next topic mark, this one will be for you, a container image deprecation for the blue ocean container. I know you did a wonderful work with Kevin letting everyone know on the Jenkins IO website, just about everywhere, you know, you maybe should get rid of blue ocean because it's not, I mean, bugs will be fixed but that's all, you shouldn't expect new features or anything like that. And of course, blue ocean containers will have the same fate one day or the other. Well, and the containers, it's even a worst story, right? Whereas blue ocean is being actively maintained at least for bug fixes, the blue ocean containers, we're lucky that the automation is working that gets them new versions because none of us are doing active work to care for those. The operating system image underneath it is not being updated. There are all sorts of legacy problems hiding there and we stopped over a year ago referencing those. So this is very valuable. However, it's gonna have to wait until after DevOps world before I make any progress on it. We'll just keep it on the list and continue reminding ourselves. Yes, we definitely have to. So yes, we will have to write some documentation on lots of different places and find a way to communicate to users. And admin, but this will be a work in progress. It hasn't started yet, but yes, that's something we'll address in the coming platform sig meetings. Now, container repository management for Jenkins agent. Yes, I can testify. This is not a simplest process ever. I remember making some proposals, pull request to change something in the Jenkins agents. And wow, I think we missed a version or a version for specific agents. It's not easy even for the pros. So yes, definitely we have to do something to simplify the release process. Anything you would add Mark? Just that we'll, we want to discuss it at the contributor summit or at DevOps world because this is one that Tim Jacome has some insights, Damian DePortal has some insights and they may have notions of how we should do this that would be better. And if we discuss them around a whiteboard in 15 or 20 minutes, things will go well. So we may, for instance, host that discussion in the Jenkins booth at DevOps world or those kinds of places. Just find a time when we can get together and say, hey, let's talk about this to see where we think it should go. Yes, that definitely is a place in the moment where we should discuss that because it's difficult to find a right time to discuss that with the right person and the contributor summit and DevOps world 2020 will be the time and the moment and the place anyhow. Cool. Next subject is required Java 11. I've seen some news this week, not really news but you know, may I say that some people were still working on getting rid of the GDK8 links somehow because some things are still referencing GDK8. So they are still minor tasks ongoing. So it's written that it's merged but not yet released for the Docker agents. Am I right? Actually, and I think it's still in progress. I'm not even sure, oh no, it has merged. Yeah, so your note is correct. I'm impressed. I thought that it was, yeah, it was actually merged two days ago. Yeah. Okay. Good work. And it's alternate plugins beginning to require Java 11. Yes, there are so many plugins we can't require Java 11 for all of them. So of course, this will take some time depending on the time maintainers have and the emergency or not. Is it mandatory to do it as soon as possible or can we still wait? But anyway, it's not a good idea to keep working with GK8 now that GDK11 is at our door. Okay. Yep. Thank you. Now, time to talk about GDK17 support in Jenkins. It's been quite a few weeks or months even now that we are working more and more with GDK17 if I were to find the infrastructure and for the time being nothing alarming everything seems to be okay, ish. Yes, yeah, as far as, well, so we've had specific reports about specific problems, one related to Active Directory and those problems are being investigated and worked. So it's not nearly as stable as Java 11 is across the whole suite of plugins but still making good progress. That's good news. Now, Java 19 has read, that would be good news. But if you like to work more, that's good news. I think you told me yesterday that the groovy upgrade required to remove illegal access warnings will make Jenkins contributors quite a lot of work, in fact, because that's a message we see more and more in lots of plugins, even in Jenkins core, I guess. So yeah, I guess a lot of people will have some tightening to do with the screws in various places to get rid of these illegal access which will now be errors and not just warnings. Am I right? Yeah, and that I'm not sure. So I'm gonna change the phrasing. It's the Docker upgrade may be required because I don't have an answer to the first question, is it now blocked? And right now don't have time to investigate to see. We still have time. I was totally a drama queen regarding that illegal access. Right. But okay, we'll see that maybe. Okay, I prefer that. Let's investigate before being so dramatic. Thank you. That's a subject we have to work on in the coming month or year we'll see. Next week is DevOps World 2022 Orlando. Oh, how come? So early. So Tuesday we'll have the contributor, Jenkins contributors summit the whole day with lots of contributors. I'm really excited when I saw the list of people who were coming to that place. And also the agenda because the subject are really, really interesting. And as I said before in this meeting, that's a perfect place and time in the euro to discuss with the right people of the right subject for Jenkins. That will be amazing, I guess. No, I'm sure. One of the subject related to platform will be with AWS people talking about EC2 instances of Mac OS. They've published a blog post in Jenkins.io last week, I guess, regarding the subject. That looks pretty difficult for QB. For me, it has always been difficult to work with the Mac OS in the cloud. And it looks like they simplify the process, but it's still kind of complicated. It's not as simple as getting something running Linux. But we need that as iOS developers or Mac OS developers. Of course, we need to have something in the cloud working. And I hope that it won't be magic anymore after the talk at contributor summit. We'll see. And they will also be from time to time in the AWS booth. So if ever we still have some questions, we will be able to ask them later on during the whole DevOps world 2022. Anyhow, last subject that I know nothing about, Mark, is supply chain security. So would you tell us a few words about that? So the prompting for this one is that about a year or two ago, the US government issued some instructions that said, hey, we expect things to improve with regard to software supply chains so that people know with confidence the source of the software component they're consuming. And one of these concepts was a software bill of materials or S-bomb. And this S-bomb concept is now apparently getting even more attention. And so it's probable that we're going to need to add some Jenkins capabilities to be able to easily and smoothly generate software bills of materials. And hopefully we're not working with NPM. That's with the nightmare. Well, you make a good point because there are many different systems that manage dependencies, right? There's the Maven dependency system, there's NPM, there's the Python PIP dependency system. There's the Ruby Gems dependency system, right? Each of them has interesting and useful things in a CI context that may need consideration as part of this kind of effort. Our most immediate is probably the Java infrastructure or the Java world and Maven because that's where the bulk of Jenkins plug-ins and core are built, but it needs more discussion. So software bill of materials is one piece of it. Then there is an additional initiative from the Linux Foundation that is attempting to make it much easier for software, for people who are delivering software to sign their components with a verifiable signature so that others can assure not just what the software bill of materials might say as to what are the components of this thing, but also here's evidence that the entity that said they were creating it is actually the entity that did create it. That's unfortunate, you know, I'm supposed to give a talk next week and one of the main thing I want to address is that mobile CI CD is very different for other software because you have to sign it, you know, it's mandatory and okay, not anymore. No, well, but your point is very well taken because we've had to sign for many years Windows installers and the Jenkins Windows installer has been signed for years but it's managed as a very, very carefully administered one-off process because the signing certificate is secret, right? And we can't expose it everywhere. This signing of components technique is attempting to make it much, much more accessible to mere mortals like me without requiring that I have to go pay extra money to buy a signing certificate and I have to go through a long credentialing process to prove that I am who I said I am to the certificate authority. There are all sorts of complexities in these signing experiences that this Linux Foundation component is trying to remove or reduce the friction between software developers and the signing process. Okay, because when someone says signing, you know most of the time I've got my hair on the neck raising up but if they remove all the pain points, I'm all for it. Well, and that's, for me, it's analogous to the kind of initiative that the people who are behind Let's Encrypt did when they made SSL security for websites much, much more approachable. They're, it's still non-trivial but it's very much more approachable and it's not costing thousands of dollars to SSL secure a website anymore. And this is the same kind of initiative, I think. Let's bring it to the individual developer the ability that they can with confidence sign a component so that others know, oh, this was signed by my authorization. Okay, and does it have a roadmap? Yeah, there's an awful lot to be learned there and I'm the wrong person to talk anymore about it. We have exhausted my total knowledge up to this point. I've shared everything I know. Thank you. I didn't know anything about that so now I know. Well, and that's part of the power of discussing at the contributor summit or at DevOps world in the quiet hours is that we can learn from others because Eve LeMere, for instance, is quite interested in this and he'll be there and we can talk with him and see what he knows. And I suspect that there are other players in the Jenkins community who are also already more aware of it and can guide us on what sorts of things should be considered. I see. That was interesting anyhow. Any other topics you are thinking of, Mark? None from me. Oh, it looks like we're done. Pretty efficient meeting once more. So if you don't have any other remark or question, let's make it decide it's done. So the recording should be available from 24 to 48 hours and see you in the next platform Sieg when it arrives.