 Okay, welcome everyone to Jenkins Docs Office Hours, EUEUS edition. It is the first edition of 2023. So happy new year to everyone. So happy to have you joining us again today and I hope the new year was wonderful for you as well. Today we've got some action items. Still talking about the Docs mailing list being archived and some blog posts that were recently published. Just a quick check on pipeline Docker plugin deprecation. There is another topic of WMI Windows agents deprecation that Mark wanted to share and just talk about when we get to that point. This was an action item but I've changed it to a regular item of archiving the website. Tickets that are on JIRA. So I've gone through the list and there are some that still just need to be discussed. We do have the next LTS change log and upgrade guide submitted as a pull request to check out as well as the web components that have been building lately and how they're actually in place now. Pull request backlog, quick note and the December newsletter which we've been talking about and will be being published soon. So anything else that I missed here or any other items that we want to add on? No? All right then. So first thing on the list, archiving the Docs mailing list and switching to community.jankins.io for the Docs SIG mailing list. This is something that I'll be working on with Mark and we'll start working on that shortly, sometime this month to get at least going on that and more details to come. And then the blog post I wanted to share. So we previously had Basil, pro and John Mark Macin's blog post in December for Jenkins plugin development requiring Java 11 and the Google summer of code mentorship, respectively. Quick note on Google summer of code mentorship. We're actually at 50 to 70 percent mentorship right now. It's a wonderful change from the last time we met. So a lot of people have stepped up and signed up to be mentors. Thank you to all of the people that have inquired, signed up, volunteered, everything. Can't do it without you. And people have already started submitting new author files and everything which is great. So really just excited to see all the new contributors joining up and mentors wanting to help. And then most recently Bruno O'Rochten's blog post on running your Jenkins agent as a service. This was just published last week. But it's a great overview tutorial of how you would create a new Jenkins node and run your Jenkins data service as the title says. Great instructions, a very nice personal field to it and personal examples. And yeah, Bruno, is there anything you'd like to share about the blog post or highlight on here or anything? Yes, first of all, thanks a lot for your help in publishing this blog post. And I think we have to know that this is not the recommended way of creating an agent. I guess there are some better ways with SSH or something like that. So this can be done more. Could you tell us more about that? So the technique is valid. There are inbound agents like this one is describing and outbound agents. Inbound agents, the benefit of an inbound agent is the agent's own system controls the start and stop of that agent. Right. So if you've got someone who's donating capacity, an inbound agent is a perfect way to do it. And the Jenkins project has a thing called the swarm plugin that sort of makes that even systematic where you could have a group of 20 or 30 people who donate sporadically their capacity. Oh, I'm going home for the night. I'm going to turn on the swarm agent. You can use my computer overnight. And that's an inbound agent, very, very good use case. The other use case, the outbound agent use case is it allows the controller to decide when it starts and stops the agent. And so it just depends where you want the control to be. Many Windows users, for example, choose to use an inbound agent because they need a Windows desktop. And if they need a Windows desktop, it's really tough from the outside of a Windows machine to log in remotely to the Windows machine and start the desktop. That's really done by a user on the desktop itself. So inbound agent works really well for Windows agents that need control of a desktop or for people who want to donate capacity. Outbound agent for, oh, I've got a cloud. I want the cloud to do the work for me. We would use an outbound agent there. Oh, thank you. It's so much clearer now that you explained it all. And I was thinking of another use case, it's when you are sometimes behind a firewall or something, you have to initiate from the inside of the company to the outside. Right, right. And that's a good one where you might say, oh, I want to donate an executor to a system that is global. There's something sitting on the public internet, the controller's on the public internet, but I want to donate resources that are inside my private network that public internet based controller correctly cannot see inside your private internet. So that's a really good use case for an inbound agent. Thank you. Thank you very much, Mark. Wonderful explanation. And Bruno, again, I super appreciate the post itself and additional insight that you also have. So this is wonderful. Thank you so much for going through and creating this. And what a great addition. And thank you, Mark. Okay, great. So next on the list is the Pipeline Docker plugin and potential future deprecation. It's very widely used and this needs a lot of discussion to determine what that effect's going to look like if and when it is deprecated. So this needs to be discussed and we need to find out just, you know, what kind of far reaching effects this could have so we can make sure to try and avoid those and just resolve everything properly. So TBD. Now, the plugin is up for adoption. And so that means that the current maintainers have said, look, this is not high on our list of maintenance. And so but it is not deprecated. And the challenge for us in the docs team is if it were to be deprecated, many of the tutorials that we have no longer work, many of the big documentation flows that we have of this is how you work with Docker don't work. And in that case, then we need a better way to do it. But I think the reality is that workflow is is so common that it won't be deprecated but there may be changes to that plugin to make it so that the less attractive pieces of it are somehow disabled or or removed because there's there's the simple way that the tutorials use. And the simple way works. And the maintainers of the previous maintainers of the plugin were willing to support that simple use. There are complicated and exotic use cases that the maintainer the previous maintainers say absolutely not I am unwilling to support that sort of strange use case and and the challenge is how do we get people to stay away from the strange ones and stay in the nice mainstream ones. We've we've taught them the mainstream ones in the tutorial, but we haven't we haven't limited the use of the plugin to only those mainstream really well defined cases. Yeah, I discovered it too late last year. Right, right, exactly. And Bruno, this you are a great example of a user in exactly that case where, hey, started down the well defined path, but then had the unfortunate privilege of discovering. Oh, there's this dark corner that I should have stayed out of. Gotcha. And, and there's not really a way to put like horse blinders so to speak on people so that they don't see those. Well, there is but it involves there there is the technique though is you split the plugin into two parts. The good parts the parts you want to preserve you you leave untouched, etc. The bad parts you mark as deprecated, and you deprecate the plugin that you just spun out brand new and say this plugin is deprecated switch to this other one. But but that's a lot more involved and requires serious development effort on the plugin to do that kind of a partitioning. Yep. Yeah, that sounds like a little bit more work. I'm sure. Well, thank you, Mark for explaining clarifying that that helps a lot. And I'm now more up to speed on that. Thank you. And then next up on the list mark is the WMI windows agents deprecation. So would you like to share what this one is about? What's going on here? Yeah, so the the story here is is there's a there's a concept in Jenkins of well, the history of Jenkins is that it started as an a monolithic application with optional plugins. But there were certain things that were inside the core that ultimately the developers of it realized this doesn't belong in core. It needs to be a plugin. And for for example, one of those was how do I start an agent on a Windows computer? Originally, that was inside core. It was a core function. You couldn't opt out of it. You couldn't remove it. It was always there. And that's unhealthy. So early on in the Jenkins lifecycle about Jenkins one dot 400 or one dot 500, that was split out from Jenkins core to be a separate plugin. Good thing, right? But that's healthy. However, any plugin that was written to depend on a Jenkins version before the split might have expected those Java classes to still be there. And thus, there is this implied dependency that is created, because the plugin says the controller correctly says, I can't promise that you don't depend on some API that was in this plugin that was in this component that's now split to a plugin. In this WMI Windows agents case, the split was fairly early in Jenkins lifecycle, 400 to 500. And there are over 300 plugins that depend on a Jenkins version earlier than that, and thus have an implied dependency on this WMI agents. With that implied dependency, it means they can't get rid of this deprecated plugin. And that's not a great experience for them. However, Jesse Glick did a little bit of investigation and realized, in this specific case, the implied dependency is actually misleading. There are only two plugins in those 300 that really depend on the plugin. All the others, it's in fact, not a dependency. So he suggested a very much more lightweight of a technique than update all 300 plugins. His suggestion is, look, let's fix Jenkins core so that this particular thing is not listed as a source of implied dependencies. Now it needs a lot of testing. I've got to do some better pull requests, etc. But the challenge is the concepts, and maybe Kevin, I'm going to put a link to the bug report where the concepts are described because I spent the time to describe the concepts in a bug report. And maybe if you can open that bug report, what this gives is a tutorial on, okay, what does deprecation mean? And why is this specific plugin deprecated? So why is technical reasons, blah, blah, blah. What's an implied dependency? That's what I described earlier. Why does it exist? Again, that's what I described earlier. Hey, it was split out of Jenkins core in 1.547. That's a long time ago, right? I mean, we're now at 2.385 with about one release a week. So we are a long ways since 1.547. But that implied dependency is there. And then now the next piece is, okay, how do you remove it? Well, there are two ways. One is you update the plugin that has the implied dependency to depend on a newer Jenkins version. That guarantees then there's no dependency. However, in this case, there are over 300. So that's a lot. The reason this is relevant for the bigger picture is because there are some other plugins like this that were split out. One in particularly Oracle JDK installer plugin that may in the future be deprecated. And it would have this same kind of pattern. So we may choose, we may choose to document this thing a little wider. I don't know. It's still a thought process. Any questions about what I just described? No, that's pretty clear for kind of a high level overview, I think. And the bugs there, the bug issues there, I can read through that and get some more sense of it. But yeah. And I thought, my main question was going to be, is it just kind of, if you modernize and improve the plugin like we have in the tutorial, that should be enough to remove that dependency at this point? Because it's going to update it to the latest version of Jenkins. It is. And that was Jesse Glick's point. He said, hey, systematically for high volume plugins, we should be updating their dependencies anyway. But then, but his point was of this set of 300 plus, only about 15 of them have more than 2000 installations. And in a system like Jenkins where there are 300,000 controllers, if you're only installed on 2000 of them, you're actually a very small subset of the total Jenkins community. Right. Got it. Okay. And then would there be something coming up like potentially a blog post to share that or? So if the change that Jesse's suggested is part of, if I can get it through and it's ultimately accepted, then what we will do is in the LTS that delivers that, we'll do an upgrade guide entry that says, if you're running one of these two or three plugins, it's actually two right now, you must remove them. Sorry, or you must yourself keep this plugin installed because we're not going to take care of it for you. And that will work. They could do it. And it's not actually that painful. So it's just a matter of gotta be sure that I've done through the right testing, the proper due diligence to be sure that yes, the change that he's suggested works and works well and is good enough to make users, the user experience good. Got it. Great. That's extremely clear now. Thank you very much, Mark, for explaining and sharing all that. Any other thoughts or items on that? Or is that everything? That's it. That's all that I had on it. Okay. Great. Thank you so much. The next thing on our agenda is the website tickets that I'm going through in either closing out if we've already taken care of them or if we just like documentation involves naturally over time. So a lot of these things have been taken care of just by virtue of doing the work normally. So I've gone through most of them. I have a few that I would like to discuss and determine whether or not we need to migrate those to GitHub or if they can be closed out or what. And I've linked the sheet here. So once we finish up the last couple items here, we'll go back and take a look through that list and see what makes sense to keep and what makes sense to close. Yeah, I like that. So Brunner, are you okay if what I was suggesting to Kevin earlier was in an earlier session, he and I were talking that we actually spend some time here in office hours to look at these issues. He's removed most of them from the list, but we look at the few that he hasn't removed and say, yeah, that's one we should keep or no, close it out. Yeah, sure. Let's go. Great. Okay. Great. Yeah. And like I said, we'll get into that as soon as I finish up. We finish the rest of the agenda so we can have time. Pull requests of note. Again, we have the change log for an upgrade guide for the next LTS, which is January 11th. So next week. And that's been submitted. Everything's ready to go there. The backporting's all been taken care of at this point. So it's ready for review and merge. And then the other pull request to note here is the web components that Gavin Morgan's been building and creating. This has actually been merged. So Jenkins.io site now has these applied to it and looks great. While you're here, Kevin, I wanted to, could we exercise one? So it's working there. Open up a new tab and open updates.jankens.io because I heard that this one may get some additional changes. Okay. That still looks pretty good to me. Okay. I don't see anything terribly bad there. Okay. Try the other one. Get.jankens.io is another site. Okay. That one's still not, and this one has always been an ugly page, if I remember right. So, okay, good. So it's still, that one still looks like generic HTML, but this one, I don't see any obvious issue with it. Okay. Thank you. That's good. Yeah. Of course. And I think this too actually is one of the other updates that I just thought were the highlight now covers the list items in the categories here, the sublinks. Yeah. Before it was just, you just click on it, but now it actually has a highlight to show that you're looking at the right thing, which is kind of neat. So little things are big difference makers. But yeah. So big, big, big, huge thank you to Gavin Morgan for doing all of that, for his continued work on that, for making these part of the Jankens.io experience. And I know that there's more to come too. So for all the continued work that will be done. We do have a backlog of pull requests right now. I think we're at about 40 to 43 is the highest altogether. So we're obviously planning on going through those and making sure that we reduce that number as much as we can. There will be more contributions coming in throughout the year. So if we can make sure that we're laser focused on the things that are coming up and relevant, then we'll be in good shape. So again, similar to the archiving, but since these are actually in GitHub, they are more likely, most likely more recent. And therefore we can take a time and discuss those things. And then last on the agenda is just a quick note on the December newsletter. So that'll most likely be published here early next week. We are working on the draft. We have updates from folks coming in. And we are working on several parts. It's going to be a big newsletter because we have to celebrate all of 2022 and highlight all the cool things that happened, all the wonderful projects and effort and work that was done. So it's going to be longer than the usual newsletter, but expect it sometime in the next week. And then the list of topics and stuff are available in the previous meeting notes. So it's your archaeologists to see what we are talking about or what we're going to highlight. It's all listed here. So you can check and share if you have suggestions by all means, share them and keep an eye out. Now, with that being said, I'm going to go ahead back to the website issues list. So these are all the ones I clearly got marked on. And then these 20 or so 18 are the ones that I wasn't 100% sure on and wanted to get a second opinion on just to make sure that I'm not totally off and saying I'm not sure if this applies still. So Kevin, could you paste the link to that sheet so that I could open on my on my machine as well? Yeah, it's it's in the document, right? Oh, yeah. Yeah. Sorry. Yeah, just just click it right in the document. Got it. Okay. Which is here sometimes. But yeah, so like, and there's stuff here like update to jam info. And I think this this actually kind of is more relevant now that there was a discussion earlier about jam set up and organizing and stuff like that. So maybe that's something to update. But I don't know if this is necessarily something we need to update for sure. There are several code link tickets and some of them are most of them are done. Some couple of them aren't. But this is also from 2020. So yeah, I wasn't really sure. I wasn't sure how relevant this would be considering it was updated before the world changed. Yeah, I would. So okay, close. This one, this one is an epic and has an epic. It it has containers of things under it. And and the things under it. Yeah, we can close those out. So for instance, update the event office role description that should just move to Jenkins.io. Let's create a website 716. Let's just create an entry on Jenkins.io to do that. Okay. So I guess this is where some of the challenges come for me like this was this was linked in the comments of the ticket and it's already been merged. So I think in this case, well, let's see, is it? Yeah. So look at the title. It says revert. So what this is is Oleg disagreed with some edits that we did and he removed them. And therefore this was his undoing something that that had been proposed. Got it. Okay. So and and in my case, I wasn't interested in fighting with him about about what the what was or was not. That's that's great. Okay. And so I'm not going to worry about it. Okay. So for me, I would I would just create create a new placeholder in Jenkins.io for that thing. The events officer description. Absolutely. Yes. And then as far as because I didn't realize it was an epic prior than mark. So what as far as the epic goes, we just leave it alone or close. I would close the epic, right? Because I oh yeah, I don't see any benefit to leaving that epic open. Yeah. And I mean, this one's going to get moved over. This doesn't seem like it's necessary anymore. So yeah. Okay. Great. And then there was oh, I noted that I did that the detach plugin documentation. So I know that we've had some recent detach plugin from Basil. Well, and that's and that's exactly what I was describing earlier. Yeah. So so that's this is this is that I had missed that this was there. Good. And so this would be this is essentially. Okay. So this is this is essentially what the you're explaining about the WMI. Exactly. The WMI windows agent deprecation is exactly this thing. Create a placeholder on Jenkins.io for this. And this one can be closed out when the when the placeholder on Jenkins.io is available because that one that's very much a hey, we just we just spent time where you had to listen to me droning on about it. And that exactly is what what I was just what I've been describing. Okay. Awesome. Great. Take care of that. Using API token with GitHub instruction. I couldn't find that on Jenkins.io as far as what they're looking for. Since they only have it in the repository, I wasn't sure. Yeah, I just wasn't sure about this one. I would just close this. I don't if I'm I don't get that one at all. Close it. Okay. Okay. Fair enough. There was this here. This is about linking to the that's not the right one. This one is about linking to the Chinese translation or essentially if someone were to go to this page specifically and then click. What do they said something specifically? Yeah, this is the right. Continue. I hope this one's fixed because we've we've tried diligently to fix. Oh, no. Interesting. Okay. Go back. Yep. So this is a specific example of a more general case. Okay. And the more general case is that we want all links in the Jenkins.io site to be site relative to be site site local. Right. We don't want them to include the www.Jenkins.io URL in the hyperlink because then they they complicate things. And if you were to look at that page on on that page, wherever the clicked link was, if you hover over it, notice that its link goes to www.Jenkins.io not to slash six. Okay. Yeah, I see. And and there's actually a you can close this one and say that it is a duplicate of another. So because it is, it's a duplicate of a request that's already open on Jenkins.io. Let's see if we can find it really quickly here. A request from Tim Jacome saying please implement this thing that yes, it's a duplicate of number 5718 prevent absolute links to Jenkins.io or www.Jenkins.io use relative links instead. Yes. Got it. You can close that. Okay. Great. Thank you very much. And then we are over time. I could I have one last one that I just wanted to check in about because it's more of a I don't even know what they're talking about thing. But they want were curious if you wanted to add SIG sub project metadata to the Jenkins.io participate pages. And I wasn't sure why this would be useful or if it would be. Oh, okay. I see. Right. So the the idea here was to consider updating the automatic automatic page generator so that the format of the pages has more information in it. I'd close this one. We'll add the information if we need it. It's now three years old. Yeah. And with that much age, there hasn't been enough interest for anyone to do it. So just close it. Okay. Great. Yeah. And I'll check in with I'll check in about the rest of them, but that takes care of most like the ones that I really wasn't sure about. And there's a couple other that need a little bit more discussion, but we'll get to it. Anyway, that takes care of everything that I had on the agenda. I want to say thank you again for joining us and welcome back. Happy New Year. I appreciate it. I'm glad everyone's here again and I look forward to next week. So we'll see you then. The video will be available in 2448 hours.