 Hello and welcome to the Jenkins documentation office hours. This is the EU U.S. edition for January 19, 2023. Today, it looks like myself, Bruno Rocton and Mark weight are joint crew, rounding out the group here. And for the agenda. A couple of action items to highlight updates about the most recent weekly and next LTS release update about WN 12 and what that means for Jenkins documentation and usage. Just a reconformation on the website component being completed. I heard a special one last week about handling regressions on Jenkins.io and how that can, if there's any nuances or additions to that. Something I was discussing with Mark is creating documentation for detached plugins, maybe even a specific detached plugins plugins page where we can house all these. And then a couple recently WM windows WMI agents being most recent and others and eventually over time things will grow old and need to be removed or moved and separated. So, some discussion on that, and a few pull requests of note that again we had a couple last week to highlight, and just added a couple more to make sure that we have them discussion if it needs. Anything else that we need to go on the agenda today, or does that cover things for everyone. Okay, I just realized one that we may want to put on a future agenda is the Google summer of code project ideas for docs that are affecting docs. So, I wouldn't put it on today's because I've not not adequately prepared but I think we ought to put it on because we owe it to ourselves to look at the project ideas discuss them think about them, and be sure that they're well vetted. So that if a new contributor wants to offer a plan for that we give them a good starting point. Definitely and I know that there are there's a couple projects specifically for documentation like moving to the site generator and screenshot automation. And I actually I'm planning on being part of the mentor group for these. So, yeah, I also invested interest in it and making sure that it goes well so we should definitely talk about that next week for sure. Cool. Thank you very much, Mark. On to the agenda. So, as far as the docs mailing list goes this is now been archived it's read only and we have the docs get our channel for communication that is shorter communication questions need help anything like that. And we also have community dot Jenkins, which is for more discourse conversation discussion in depth topics that we really want to share on and collaborate and expand on. So there are multiple places to still get in touch. And the mailing list is still available it's just in a read only format so if there are any reasons to check that out, you still can. And for blog posts we recently had our 22 recap blog posts published. I know we mentioned it last week but just again thank you to everyone that worked on this is a lot of work and a lot of collaboration that resulted in a really nice highlight of Jenkins and 22. Thanks to Bruno thanks to Alyssa Tong, and several other contributors who worked on all of the information that was in there and getting it together. And speaking of Google summer of code, john markness and has written a blog post on being a mentor for Google summer of code that outlines a lot of what goes into being a mentor, some expectations and thoughts behind it. It's a really great resource to consider and check up on for any sort of mentorship whether it's Google summer of code or something else. And take a minute if you have. And if you're interested in all in Google summer of code we still are definitely accepting applications for mentorship and other aspects of it where we still have plenty of time to go and the summer of code doesn't officially start until the end of April begin the end of May ish so we have lots of time to work on these things contribute get familiarized with stuff. So, again, anytime you have, it's a good idea. Next up, we have the releases so we had weekly release 2.387 this week which released successfully. So everything's all good and fun there. Mark Thank you again for handling the chain log on that. And then for our next LTS release we have 2.375.3 that will be happening on February 8. I've already created the chain blog and upgrade guide so that link is available here for any reviews it's a smaller update, just as in previous ones that were point 2.3. So, not a ton, but still there, then I would still appreciate any feedback. The next item on the wrist is the Debbie and 12 release. And so Debbie and 12 release which is planned for April 2023 or getting close to that point is going to deliver on JDK open JDK 17 not JDK open JDK 11. Jenkins already supports Jenkins Java 11 and 17 so this isn't an issue in that sense and with Java 17 being the future and you know current recommendation we're we're going to move towards that as well and make sure that the Jenkins documentation is highlighting Java 17 as the way to go and the best method for usage so that all the functionalities are there. Proper steps, proper actions are taking instructions makes sense and apply correctly across the board. Just all the benefits that would come along with having that update available will be felt across the documentation as well. Well, on that one that that red hat universal base image topic there. Maybe you could go ahead and open that. Yeah, a contributor from red hat has submitted a proposal, recommending that we add a Docker container image for the red hat universal base image nine we already shipped one for universal base image eight and nine has now released. We've been released for quite a while we're now on nine dot one. And, and so, I think it's a good idea, I think this is the right approach, but the question to the contributor was, is it intentional that you're doing Java 11. We consider here doing Java 17 as the container image, and they, one of the key sponsors all of our goncha is who also was our release office or many for many years. So, very experienced with Jenkins, etc. said oh yeah we'll probably need Java 17 pretty soon maybe we should just make this one Java 17. Maybe my preference is let's make this one Java 17 not that it's required, not that it's mandatory but doing Java 11 on the brand new red hat operating system, you be I nine feels backwards, let's do Java 17 as the first preference. It's, it's leading out so that when as we make the transition in April or May to more actively documenting Java 17 and more places. It's just a natural part of that. And that's all that you can put that away now Kevin thank you. Okay, thanks Mark. And, yeah, no I appreciate that Mark thanks for providing all the context and kind of background to that. So, amazing and keep an eye out for that. Next up here on the agenda. Just a note again, the website component on JIRA has been completed so there are no more Jenkins.io website tickets on the Jenkins JIRA those are in GitHub now being in the GitHub issues tracker. And from here on out that's where they'll be submitted to so that's taken care of we're already. Let's go let's take care of. Next on the list is how we handle regressions on Jenkins.io. This is something that we discussed last week about how the Jenkins core team handles regressions and how they go about resolving them or reverting them depending on what needs to happen. And we checked out some examples. Recently the Jumbotron is not currently rotating and the sponsor images had been sized a little incorrectly. So, these are things that may not have been site breaking or impactful to many users they did take a little bit longer to come on to our radar. But the fact of the matter is these are regressions that we're that people are experiencing and we have to make sure that we're taking care of these properly. We went and created labels for major regression and regression, so that when these are submitted in the issue tracker we know just how severe it could be. If it's absolutely breaking if it's super minor if it's, you know, and anything in between. So, also talked about using the same processes core where if it is breaking reverting it within a couple hours less than a day I want to say mark if I'm not mistaken. And then, depending on the severity of the issue we can assess from there we can figure out what needs to happen and prioritize accordingly. It's not something that is set in stone right now because we are just starting to adapt this so. This is super open for feedback and ideas and if anyone has preferences or previous experiences that might lend themselves to this sort of thing more than happy to hear. Eric, did you have anything you wanted to add for the regressions on Jenkins.io. Nope, I think I think we've got a good plan there we may ultimately want to document that in the contributing guide. In fact, I think we will want to put it in the contributing guide for Jenkins.io. That's that's where it ultimately belongs I think but for right now. We're working out what we what we agree on and then we can put it into the contributing guide later. It's the contributing guide is the formal documentation location for it for me this is a good excuse to discuss it to talk with European contributors to talk with contributors from Asia. And after we get through a little bit of discussion then we formalize it as a pull request to the contributing guide. That's that makes sense that sounds like a good plan. So, yeah, awesome. Next up on the agenda. So this is something that I was talking to Mark about just prior to the meeting. There are detached plugins that exist within Jenkins. There's the new MI agents Oracle JDK tool. There are more on the list here of course you can see software configuration management plugins authentication plugins miscellaneous build tool plugins like there's a lot of there are a handful of detached plugins that could be more noticeable to folks and others depending on their use case. But ultimately, if these are attached. users are going to be curious as to how they can remove themselves or separate those things out themselves. If they're running an older version of Jenkins as their baseline they may not have noticed but the second they update they're going to notice. There needs to be some sort of not formal instruction but we we should give insight as to what's going on with background and how to take care of this on for user. So, go ahead, Mark. I was just going to I was going to offer a description of a case that a real Jenkins user may encounter so I'm a Jenkins user running on windows. I've got the most recent long term support or the most recent way you don't have to put in the notes in there and just, just I'm running, I'm running on windows. So I've got a controller on windows, it's meeting my needs is doing exactly what I want. I can use Windows Active Directory for authentication. But I can't uninstall the Pam authentication plugin, because I'm dependent on another plugin that has an old Jenkins base version, an old Jenkins minimum version and it makes the Pam authentication plugin and implied dependency. I'm stuck with Pam off, which is a very unix thing right I know I will never use it on my windows controller, never. But I can't uninstall it, because the implied dependency on these other plugins that are have an old baseline, but I need them. And so that that story is a bad story for the user or I absolutely know I'm never going to use subversion. I know it. And yet because I have some old plugin installed. I have to, I have to also install. So I have to also have subversion installed. So it's just it's unhealthy for Jenkins administrators to have plugins installed that they don't use. But these split out plugins, they can't remove them, because if they remove them, they come back the next time they restart. And it's, it's that's that story of detached plugins. And, and there are lots of complications hiding there that WMI agents is just the first. If someone were to deprecate the CBS plugin, there would be a lot of WMI agent style angst out in the world, they would say, but CBS is actually not used very often anymore as a source control system right there just aren't many projects that use it. So you could say, hey, somebody might deprecate it then they say we're not maintaining this thing or maybe a critical problem is discovered that it's got a security issue in it. And no one fixes it. Now you get a report in Jenkins that says this plugin has a known vulnerability you try to remove it. And it says I'm sorry you can't remove it because there's this implied dependency. So there are lots of dangers in this in these split plugins that haven't shown yet. WMI agents is only the first but this place has some has some risks in it. Got it. Thank you very much Mark. Sorry long, long boring discussion but That makes sense that helps clarify it's better way better to give some real context to it in a real situation that someone might find themselves in. That's not boring that's real. That's more important. Yeah, no I appreciate it and yeah and like I said that this is still this is very much just preliminary ideas. There's other plugins or anything that anyone has they've run into something they have an idea for they have maybe some insider knowledge of what might be going on as far as deprecation like anything at all. The discussion is here we're more than happy to listen and share and again open to anything. And then last thing on my list here on the agenda is just pull requests of note. Again, a couple of these were we talked about last week, the updating Jenkins guide that Vandy has submitted and thank you to Vandy for all these submissions lately. A lot of work being taken on and it's, it's kind of impressive in every sense of the word. Vandy wanted to add a guide on how to actually update Jenkins on Linux, mostly think there might have been a couple. Yeah windows as well. This is a lot of content and a lot of information to add to the Jenkins documentation. I know that I'm still going through and marks going to go be going through and reviewing suggesting anything that we need to so that this can go smoothly and be added smoothly. Anyone else is welcome to review the pull request is open. Any ideas or feedback is appreciated on there. And another user, I forget who exactly Hector Peebo had submitted a pull request about adding a light TPD reverse proxy. I reviewed it documentation was I'm not an expert in reverse proxies by any means so I had a smart to assist with some of the review on that and if anyone else wants to check it out. And if you go through the instructions see if everything works out for them, by all means, it's much appreciated. And third fourth fifth set eyes never hurts. And then this pull request here is one that actually came into the Docker repo. And this is about uninstalling a plug in through Docker or with Docker. I forget mark exactly. Yeah. Well, and what the author has done is they've documented how to uninstall plugins in multiple with multiple techniques the challenge is that the technique I haven't I got to review it again but the technique they use for Docker has has failure modes where it doesn't work as expected. And that's because uninstalling a plug in a Docker containers more complicated. Yeah. Sorry. And even worse than that. It's also describing a technique with Jenkins client, which is supposed to remove plugins, except that the commands which are listed do not exist to my knowledge so I don't know what to do with that. And I think I believe the author has removed that reference so I think I think that part's okay now because saying saying that there's a command line that is it doesn't exist. Okay, that's bad. But but the other it just needs more, more review and somebody who's familiar with Docker to try it and see does the do the instructions work as given. Yeah, my fault. I have to review it once again and try the comments once again. I should have done it this week but it got out of my mind. Sorry. And I think the main thing that I wanted to mention on this is that if this, you know if this does work out and this is submitted emerged eventually that is documentation that would have to make its way over to Jenkins. Well, so not immediate effect but down the line that will be something that we should consider and plan on moving over or at least including in the Jenkins documentation. And then, ultimately, this pull request was actually. Well, it's still open, but it's closer to being approved emerged than not. So we're taking Vendee again had submitted another pull request to add some content on this time to the pipeline syntax reference. And when adding this parameter information. We looked at it and said, this seems like it's getting a little more than what the syntax page should represent or share. So I made the suggestion that, hey, why don't we take that put it somewhere else where would be able to put it where can we add that in because that does help give insight to this so talking about maybe having a parameter page or page specifically for these sort of things because while I've found documentation for things like the environment variables. And so, we'll obviously want to make sure this, this is what the Jenkins documentation is thorough and informative so. Well and parameterized builds have some interesting, interesting cases that are worth discussion. One of them that Vendee discussed was what happens if I name, add two arguments and the two arguments have the same name. So I add a twice. Alright, that's that's a don't do that but if you do what happens. And, and those kinds of things that are much broader than just pipeline syntax right that's any parameterized job has that characteristic. And there are other cases what happens if I define a parameterized job in the Jenkins file, what happens when I'm using that Jenkins file inside a standard pipeline project not a multi branch. It's, there are there are some interesting cases and they, as you said Kevin they all, all deserve a different place than in pipeline syntax. Great. Thank you. Thank you very much Mark. That helps explain the idea and everything a lot more. And, yeah, like I said I, and we've talked about this too in that the syntax page should be a quick reference not an extended book about these, these matters. That's what the rest of the documentation is for so we can utilize that to its fullest extent. And it actually covers for the agenda I had. Just to make sure there anything anyone else wanted to talk about mentioned chair. Great. Okay. I will go ahead and stop the recording, it'll be available in about 24 to 48 hours. And thank you again for. Yes, stop the recording definitely the reminder is, I haven't posted the last Docs office hours yet either. So, so I will get that posted, both of them.