 Hello, and welcome to the Jenkins documentation office hours. Today is July 20th, 2023, and this is the EU-US version. Today we have myself and Bernover Upton. Mark waits on well-deserved PTO, so hopefully enjoying the time off, and we'll see him when he gets back. Just briefly tonight, or July 21st, Asia Docs office hours, it's canceled because Mark is on PTO and he's unavailable. We'll just remind again at the end of the session, but just put that out there. Today on the agenda, so a couple of blog posts that were recently posted, LTS information, and next LTS information. Last week's security advisory, quick updates on Google Summer of Code, the transition for Java 17 usage in the documentation, a couple open pull requests of interests, some notes on DevOps World Tour, and again, Mark's well-deserved PTO and how that affects scheduling going for the next session. Anything else that you want to throw on here, Bern, or anything that would be worth discussing? No, thank you, Kevin. Okay, sounds good. All right, so first up, the blog post. So just the last week or two, we had the June newsletter published and Damian de Portaille actually wrote up a nice post-mortem for the infrastructure outage that happened on, I think it was July 7th that it came up. Really goes into detail, talks about their actions, how they figured it out, what they were gonna be doing in the future to alleviate that and prepare better next time. So just really great information here. If you're curious, feel free to check it out. We had the weekly release 2.415, this past Tuesday went through successfully. And coming up next week, we have LTS 2.401.3 to be released. That'll be on Wednesday, July 26th. Change log's already been merged at this point in time. So that's good to go, not a whole lot there since we've been pretty successful lately. So yeah, they'll be ready to go. And then the next LTS baseline discussion has started in the developer mailing list. Right now, the front runner looks to be 2.414. It's been very successful, no issues to speak of or any issues that have come up. We've been discussed in that mailing list conversation. 2.414 has been supported by most people and it's actually been accepted by Tingicom as the release officer. So that's most likely gonna be the case. The change log upgrade guide will need to be created for that, but this is gonna be happening sometime later in August. So we still have time to get that taken care of. Last week, there was a security advisory published. This was for plugins. Something to note with this advisory is there at the bottom of the list, there are a list of security vulnerabilities that have no fixes. One thing that we pointed out last week was the rebuilder plugin. That's actually been removed from the suggested install plugins. It's still available if you want to, but it's been removed from the default and recommended plugin installations when it's installing Jenkins. As of, I think it was backported actually as of 2.401.2, that could be wrong. But actually, no, that would have been way too far back. I think if anything, it was backported into the weekly release, forget exactly, but it's been removed. Okay, and also so that the test aggregator result plugin was removed also. I don't think it was part of the basic installation. I think I had installed it by myself, but test results aggregator plugin. Yeah, I had to remove it this week. It's captured. Yep. So yeah, so we have been made aware of these things. The security team is actually working on making sure this is noted and the infrastructure team is also making sure that these things are resolved and these issues are sorted. So it's just great work by everyone overall to help keep Jenkins healthy. So thanks to everyone for their incredible work on this. Google Summer of Code has been moving along nicely. So we just had the midterm presentations a couple of weeks ago. Last week, we had the mentor evaluations do. Things are making great progress for the most part. Thank you very much to the participants for joining up and doing all this work. And the recording from the midterm presentations is available if you wanna go back and watch it. Everyone's able to just bring a lot of perspective and share their work, their progress, their challenges. And it's really nice to just get that insight from the folks that are on this project. So thanks to all the participants for their constant work on this and everything so far. And really massive thank you to all the org admins, Bruno, Alyssa, Jean-Marc, Chris Stern for helping make sure that this is successful and running this and being the guidance that we all made in this. So yeah, really great. And just something that we'll be looking forward to in the future, the Jenkins.io site building, being built with alternative tools. So right now the testing is being done with Antora. So this would actually more closely align with other tech documentation. For instance, CloudBees uses that I know and various other solutions and other platforms are using this too. It allows for version documentation, which is great. So we can have the various LTS and weekly release versions, documentation support them directly and specifically so that no more issues in the future of having to worry about, well, we're putting like the Java 17 transition. Obviously Java 17 wouldn't be supported by older versions, but we can make it so that the documentation reflects that by making sure that it's attached to the correct versions. So I think it's gonna be really nice. And the amount of work that's been done here has been really great. The navigation is really smooth. Everything is presented really cleanly. And even things like, I think it was just an illustration. Yeah, something I noticed last time when we looked at this, things like the reverse proxy configuration would normally have to be clicked into to actually see this on the page. But in the Antora version of the documentation, the dropdown actually expands, which is nice. The collapse is removed and we can see all the different reverse proxy options as close to right now if we were to look at the same thing. You can see here, it's just one option, but then if we click it, you get the list of reverse proxy options. So things like that, having to scroll down the navigation here versus not having to is nice to everything's just present. So lots more to come with that. There's still plenty of work to be done, but yeah, it looks really good. And thanks to Vandy for doing that work. As far as the Java 11 to Java 17 transition goes, so I've made some a good amount of headway in the last couple of weeks. I've been able to update a lot of the regular documentation for Java 17. So things like the Linux installation docs, Docker installation docs, using Docker in pipeline, architecting, manageability, you can see the list here. And we do have an issue, I didn't link it here for some reason, but the issue is currently tracking all of the pull requests and has a list, a running list of what we're updating. I've also, as of, I wanna say yesterday, we now actually have instructions on upgrading the Jenkins Java version from 11 to 17. Darren Pope's created a video that actually walks through this. So we've included that. And for the most part, the instructions are one for one for the eight to 11 instructions. Biggest difference is things like the Java Webstart being removed, don't need to be pulled out here since we're going from a point where it already has been an 11 to 17, which still doesn't include it. So we've cut out any unnecessary info here, but we wanna make sure that this is a seamless experience and that people are able to follow the instructions and get the results they need. One of the bigger things that we changed is just making sure that people have their plugins updated prior to doing any sort of updating. This is a hugely important step that it was not actually put into the eight to 11 upgrade. So I'm making sure to include it here. I'm probably gonna go back, honestly. Well, we might not go back and update the eight to 11 since that won't be relevant soon enough, but updating plugins before upgrading everything is hugely, hugely important in the process. And once again, doing so after you've upgraded Jenkins as well, making sure that everything is properly updated and supported is crucial. So made sure to put that in here and might add some more context into the upgrading plugin section. It's again, taken directly from the eight to 11 instructions, but I think that might be worth putting some more context in there. Yeah, we often see posts on community.jnkain.io of people upgrading, you know, even not the GDK version, just their Jenkins version without updating the plugin first. And some of them experienced some issues, of course, before upgrading GDK or Jenkins, please, please, please update your plugins. Yeah, and if there are any number of stories out there about what happened, you don't. You don't have to look far. You can search on community.jnkain.io. And there is plenty of other resources out there, but that's something that we want to try and curb going forward. So making sure that we have that explicitly called out is step number one. And almost being said, sort of right now, there's nothing tentatively planned, but I'm thinking that with all of these updates and transition, a blog post announcing it and sharing that would probably be a great idea. So once I've actually gotten through some more of the tutorials and other documentation, I'm gonna go ahead and just create a short blog post announcing this and describing that background why, explaining how this is still, this isn't dropping any support for Java 11, et cetera, et cetera. Yeah, it doesn't need to be anything too, too crazy, but I think we owe it to users to share, hey, just so you know, this is a thing that we're doing and we have been doing and why, so. Yeah, and thanks a lot for that because the Maven tutorial, the Python tutorial, the other tutorials, with Ashutosh for the GSOC project, we are working on a new version of them, you know, when we will simplify the process. But having it rewritten beforehand will simplify our job later on. So thanks a lot for what you're doing. I've seen the reviews, I've seen what you've done and frankly, it's brilliant. It's really a better documentation. All you need to say. Thanks, Bruno, appreciate it. Yeah, and like, and I just wanna share, so this is, so the first one I've gotten through is the Build a Java app with Maven tutorial. For the most part, I have done everything in my power not to change any of the actual instructions. The wording has been changed a little bit to make it read a little bit better and some punctuation formatting mostly. And then I've gone through and some of the, and like, this is the biggest thing that I've done and done as the Maven 3.93 Eclipse Timeran going from 11 to 17. Yeah. We may talk about that in a few minutes from now because you had to do it by hand and I have a proposal that you already know about, but a few minutes from now we'll talk about that. Yeah, no, and I think I know where you're going with that and I'm not opposed to it whatsoever. Yeah, because I think there's a way to probably put a placeholder in there that would automatically take care of that for me. I know that Mark has done that with, I think we were doing it for Maven 3.90, 9.0. But yeah, I'm very interested in knowing what we can do about that because I like it a lot. Okay, thank you. But yeah, so, and I've gotten some review from my other fellow documentation writer. So they've helped me get this even better arranged and honestly, the syntax and content updates just from a standpoint of simplifying some of these instructions makes a lot more sense. Yeah. So yeah, I'm hoping that I can get some reviews from other folks, maybe some big matter experts or anyone who's built a job app like following this tutorial. Be great, but it's available, it's out there and it'll be open until we have some proper review from Jenkins folks as well. But yeah, so that's coming next and then I have the other tutorials on my list to do as well. The guided tour is not gonna be updated as I thought it was because Mark and I were able to discuss previously the way that the guided tour setup is not, it's showing how the tools run in Jenkins, not that the Java version needs to be up, like it's not the same process in that sense. So we're leaving the guided tour alone for the time being but we're working towards making sure that the other tutorials and everything else is probably alive. So to open pull requests to talk about, so Finneuge has submitted this pull request for administering Jenkins when Kubernetes got a great start, just needs review from people that have Kubernetes experience or expertise. So anyone that wants to pop over and check it out, feel free, share, provide feedback, it's always welcome. Jeffrey Chen submitted a best practices page migration from the Jenkins wiki. So I had a couple of bumps along the road but we got this to a point where it's acceptable and it has now been merged, it is live and the Jenkins best practices page is available from the site. Yeah, and we talked last week about how best practices is a good idea and how these are recommended, but these are the kind of things that best practices is a discussion to be had at some point, if it comes down to it, someone else's best practice might actually work better or someone's best practices that they've been using may not align with ours. So that's the kind of conversation that we should be having and wanna have and find out ways to improve or things that we can change or add to this page. This is definitely one of the more ongoing pages that we'll have. So any new best practices, anything that comes up with the various new projects we've got going on with Google Summer, like there's a lot of different places that we could even get more best practices from. Projects like Hacktoberfest can actually even expose new best practices based on, we've got new people coming in, they have different viewpoints and perspectives and maybe no experience or different experiences with this sort of thing that kind of exposure really helps us understand more and more and can help these best practices expand. So anything on the best practices page Bruno or you're just excited about having it there? Yeah, that's right. I think I made a review of this, at least I've read it and I was really happy. I discovered some things. In fact, so I'm super happy that it's now part of the Genkinsia website. Good, awesome. That's great. I'm glad to hear it. It sounds like it's already serving its purposes. Yeah. Good, next up. So if there's 15th Treaty Page, this full request has been existed for a little bit. It's got a lot of comments and review but needs more review and feedback. Mark or I would be able to start working on that but it's a little bit lower priority than the job of 17 transition. So it might not be worked on for a little bit still but it's there, it's not going away. And it's part of the pull requests that we found are valuable and usable. So regardless of what happens next, that contents stuff that we need and it will be used. And then the using update CII for Jenkins, I'm guessing this is the one that you wanted to, that you're referring to. Yes, sorry for the shameless plug. Yes, it's something I've been working on for quite a few weeks now, not a lot but I've been getting some feedback and changing a few things here and there but some community members didn't feel like it was something which was much needed and some other people thought that it was much needed but not with that tool, update CII because some other tools like renovate boat or dependable already do that kind of things. But I propose to do it with update CII because I know just a little bit better update CII and for some of the tasks that I was proposing it may be difficult to do with other tools or even impossible to do. So that's why I chose update CII. I'm trying to force push this PR another tool. First of all, this was just a matter to discuss the subject. Should we continue to upgrade the dependencies by hand or could we automate that? Now I have a fork of Jenkins IO of course on my GitHub account and I have run that and it created eight PRs for me that prove somehow this could work for Jenkins IO. I'm supposed to have nine PRs but for whatever reason I think it's PHP or Python that is not yet up to date on Docker Hub with the latest alpine version. That's why there are eight and nine, whatever. So what I was proposing is that people interested in that subject vote with a sum up or thumb down in a few weeks from now, maybe we could choose should we close this pull request or merge it if we have more thumbs up that thumbs down. Totally open to one or the other solution. Just wanted to show that this can be done. Oh, I got a thumb up. I'll kick us off the right way. I think it's really great, Bruno. I think that it's, I could understand if it is not ideal like the right way to do it's not ideal for other applications or other functions and stuff but I think for something like this it's perfect and it clearly works really well. You've got PR showing as much. And yeah, I mean for what I'm doing this would be really useful and helpful in the sense of just being able to say, okay, update all these and be done with it. And then that's a lot easier than having like you said having to go through manually updated put it submit all that stuff whereas. But the thing is it's still somehow manual because whenever you will be writing another piece of documentation. Nothing, you have nothing to do right in the documentation, okay? It's more or less automatic but you will have to modify the update CLI or workflow flies in order to have your, yeah, new piece of documentation update all automatically. Yeah, so yes, it's automatic but whenever you will create all the parts of documentation, your automation will still need somebody to change something in the configuration files. And I don't know how to automate, you know? I probably that so I should be the maintainer of these update CLI files but I should know when somebody adds something to Jenkins.io that would need to be updated thanks to update CLI. So I don't know, I'm still partial about that. Of course I want to do that but I don't know how to be informed. I used to be subscribed to every Jenkins.io PR or issue and I just couldn't manage it because there were so many of them. So I don't know how to filter that so that I know that have something to do but that's for another month or so if ever this was merged. Yeah, I mean, I don't think there's an issue. Well, okay. I don't see an issue with having to update the CLI file in the first place to have everything else update. Like to me that makes sense because yes, it's automatic and yes, you're having it run and do these updates but at the same time, like how does it know what to update it if you don't tell it kind of thing? And so that like that part makes sense to me but I also could see why automating even that process would be helpful in the long run. So you have one less thing to deal with and worry about all that but for what we're looking at already I think that's really great and I think that works really well. I have no problem personally adding, if that is the end result but I have to make sure that I update that or add that in myself prior to it running I'm okay with adding that step to my workflow if it takes away five others or six others or whatever that might look like but in time we'll get there. We'll figure it out. But I think it works really great. I mean, for what it's worth, I like it a lot and I like the concept and I think it's really worthwhile. Like yeah, like you said, there's the Penderbot and Renovatebot and like other things but that doesn't mean that there can't be another useful tool that we're relying on to help us. Maybe we should just use the best tool for the best use. I mean, Update CLI won't be the best tool for each and every dependency update. Renovatebot could be useful for other ones and of course, I think we already have the Penderbot working on Jenkins.io. So why not combine the three of them to get most of the automation done? We'll see, anyhow, thanks a lot for your feedback and for the thumbs up. I do appreciate it. Always give you a roll on too. Yeah, no, and like you're right why shouldn't we combine tools? Why shouldn't we try to make our lives easier in that sense? Like, if it's possible, we can do it. Why not? So thank you very much for sharing all that, Bruno and you're kind of walking us through and explaining the process a little bit that helps a lot. And I think as long as we can get more eyes on it and people see what the goal is and I don't see a lot of people would be opposed frankly, outside of, I could see an argument like it's too many things but like even then, I don't. That's a, I can see that as a personal view versus like a factual thing. So we'll see, but. Thank you, Gaby. Any time. Cool, so next up, so DevOps world is happening again this year as expected. However, the format is different. This year it's gonna be a DevOps world tour. So the idea is a smaller one or two days show, days at most and kind of compacting everything to one day instead of having one conference in one place that may be more difficult to get to or attend or be a part of at that point. So what's happening is DevOps is gonna be going DevOps world tour. There's gonna be multiple locations. So places in the US, for instance, New York, Chicago, Silicon Valley. We're doing, there's gonna be one in London, Singapore. So multiple dates, multiple days for some of these dates and the speakers and talks that'll be had are already being determined, developed. Mark, wait's actually gonna be at the US locations to give a talk, title, benefit your business by contributing to open source. So plenty of incentive right there to go to one, if not all of them. And yeah, and we're gonna like forget who but I think we're gonna try and have Olivia Lame and for the Singapore, since he's over there. Bruno, are you gonna be at the London one or I know? No, I think Tim Jocombe will be the one who will do the talk in London. Yeah, as he's a local, oh. Oh, okay, got it, got it, I always forget where Tim is, so good to know. But yeah, so the reputation's gonna be there. Registration's open now, you can sign up and yeah, just get excited, it'll be there and more details are available on the site. So if you have questions, check it out. And then last but not least, since we are out of time. So Mark is still, is on PTO again. He will be unavailable for this evening, tomorrow, whatever time zone for Asia Docs office hours. So the meeting is canceled, he'll be back next week. So July 27th, Asia Docs office hours will be back on as normal. Yeah, and that wraps us up for today. So I'm gonna go ahead and stop the recording in just a moment, video will be available 24 to 48 hours, same as normal. And we'll see you next week. Thanks for coming by and have a good rest of your day. Thanks, bye, Kiwi.