 starts now. Welcome to the Jenkins documentation office hours. Today is January 12th, 2023. Today we have myself, Mark, Wade and Bruno Barak been joining us. Thank you all for being here. Today on the agenda, a couple things in the action items. One, we have archived the docs mailing list. So just a quick update on that blog posts. We have an update on Debian 12 and what it will deliver. Mark, would you be able to share more about that? Sure. This is one that Bruno and I will probably talk as well about in the platform SIG meeting, but it has a documentation impact. So I discovered just yesterday that the next release of Debian, scheduled for 2023, will not include OpenJDK11 at all. The package won't be available in it. They're offering Java 17, which means they're really preparing also. I'm sure once Java 21 is available, they will include it, but that'll happen, what, six months or a year from now. So Debian is correctly saying, look, Java 8 is done, that was done for them a while ago, Java 11 is really also done. The impact for us is that when they release in roughly April of 2023, our Linux install instructions will have to be, yeah, so what you see here is they don't commit to a final delivery date. What they commit to though is they're currently planned for March 12th to be frozen, exactly, hard freeze. Full freeze is where they reach the final release. Usually it's a month or more between hard freeze and final delivery. So I'm not expecting this before April. Once they release it, we will probably switch the Jenkins Docker containers to use this new version of Debian. That makes sense, but users who are installing with the apt package or who are using our default instructions won't be able to do that anymore because they'll, our instructions tell them to install Java 11. So April is about the time where we should probably start saying, maybe it really is time to transition the default instructions on at least Ubuntu and Debian Linux to use Java 17. Gotcha. That makes sense with moving into the future, Java 17 is now available in Jenkins fully, so the reason to not include it. Exactly. And there's no, it's not mandatory that they have to use Java 17, but us changing using this event, the release of Debian 12, as our excuse to say we're switching also to document Java 17 as our preferred path, feels like a healthy thing to do. Yeah, I agree. And it's not saying that Java 11 is going to get not to not getting supported any longer. It's just a matter of, hey, Java 17 is new. We want to make sure that this is encouraged and provide the correct instructions for users. Right. And if they choose, oh, I'm going to install Java 11 instead of Java 17, great. It's just that about that time, we switched to where we say we're going to recommend Java 17, not because that's the only thing we support, but because it's simpler to give those instructions in this case. And we do fully support it. Got it. Wonderful. Okay. Awesome. Thank you so much, Mark. That helps clarify all that. Okay. Okay. For the rest of the agenda, archive website tickets, small update on that, handling regression, how we're going to handle regressions on the Jenkins.io site itself, some pull requests of note from the community, and just a small discussion, short discussion about one of the using agents page in Jenkins. There was some feedback and I would love to get some perspective on it from others to see how we can improve. Anything else that I might have missed today? Or does that cover it for everyone? Good agenda for me. For me too. All right. Thank you very much. Okay. So first thing on the list, the docs mailing list has been archived. It's been made read only. And now the main idea is we're using the Jenkins docs getter for communication. So this is where we are announcing docs office hours. This is where we have discussions regarding documentation. Just kind of any ideas here. And community.jankens.io will be the second location. And this is going to be for more in-depth and involved conversations if there needs to be research, work done, anything that is more than a short conversation would be best had here. And the nice thing about having it on community.jankens.io is that it's available for everyone to see. Much easier. Not everyone might be using getter or the chat, but if they have an account, they have the ability to see community. So it's been another good place to have it and we'll make the transition to the future seamless. A couple things, a couple blog posts to highlight. Sorry. So today we just published our 2022 recap newsletter for Jenkins. So huge and massive thanks to everyone for their work on this. The entire community team came together and really made this something special. There's a lot of great, great updates on here. Thank you to Roxanne from CD Foundation for providing these image headers for us. They are wonderful and really make it stand out. This is, everyone's hard work is on display here. And this is truly a test example of the love and care and work that Jenkins has been getting for 2022. Sorry. By all means, take a moment to look it over, read it, we'll be tweeting it out and posting about it online. So this is everywhere now and it will be even more places by the end of the meeting. And then a couple other blog posts that were recently published. Bruno had a blog post recently on running your Jenkins agent as a service. Again, a nice tutorial alternative methods of using a Jenkins agent. Great instructions here and a really nice, just break down by Bruno. Thank you. And the other one here is John Mark Messon's blog for the Google Summer of Code mentorship. We are getting a lot of participants. We're about 20 or so participants already signed up. We're looking for mentors. We're looking for co-mentors, et cetera. Anyone that is interested is more than welcome to come on and sign up, help, you know, contribute if they have that desire. The blog post here mentions more about what mentorship looks like, what it requires, what the expectations are, where you can go to get more information regarding Google Summer of Code, for instance, and just provides a great little set of expectations ultimately. We did already talk about the Debian 12 release and what that means for Jenkins and the Jenkins documentation. And yeah, is there anything else on that one, Mark, that you want to mention? No, actually, I'm a little embarrassed. You asked, should it be on the agenda? I wasted the time describing it. It's done. I think we have a good decision. We will plan for, as Debian 12 arrives, there are going to be a bunch of activities that will happen, Docker container updates, documentation updates, et cetera. And as part of that, we'll switch to Java 17 for sure for that platform. If ever you have some questions about that later on, tomorrow we have the Jenkins platform SIG where I will ask Mark stupid questions about that very subject. So stay tuned. Perfect time. Great. I'll be there, no worries. Thank you. Thank you. And then the next on the agenda here, so we had a list of issues that were in JIRA still that were assigned with the website label. These were issues relating to the Jenkins IOS site. We have now officially closed out all of the website tickets. Anything that was irrelevant at this point in time, since there were some from 2017 and earlier, to the ones that have come in recently have been migrated. Anything that really should be discussed further or acted on has been migrated to the GitHub issue track issues list now. So anything else has either been handled by just natural evolution of the Jenkins IOS site or documentation has become, you know, things have moved past it in terms of update and version. Or like I said, if it was super, if it was something that we want to work on and action on, it's been migrated so that we can keep that focus. The next thing in the agenda is how we are going to handle regressions on the Jenkins IOS site. I was able to talk with Mark about this and get a little bit better understanding. And so the idea is that if there are regressions on Jenkins.io, such as the two examples we've got here. Yeah, you've got to open those two because those two are somewhat sources of shame. Okay, this is the mark, the first one is the Mark weight source of shame. Okay, so what we see here is the Jenkins, what we call the Jumbotron, it's the this thing that rotates down at the bottom of the big orange block. However, it stopped rotating apparently in November, late November of 2022. Yeah, so we regressed the site and we haven't, it's taken us almost eight weeks to detect this regression. So apparently it's, and thank you, keep scrolling down Kevin because it's a good story, special thanks to Vandit who did the bisect to find out which commit caused the cause the thing to first appear. Exactly, good job using a bisect and and figuring out, hey, this is it. That's that's work that Wow, none of us had to do. So very, very grateful to him. Now the question is, all right, what do we do next with it? And the I like the technique that Jenkins core uses, where if a detection, if a regression is detected in Jenkins core, Basel Crow has been guiding people, we will give a very, we will give a time where the original regression is identified. And the author of the original regression is given a reasonable amount of time to either resolve it, or we revert. Because we want to be functional, right, we want, we want to retain functionality. And in this case, the embarrassing part for me was, because it took us eight weeks to detect the regression, I propose that we need it fixed within one or two weeks, because of just how long it took to detect it. I think the answer is it can't be that serious of a regression, if we didn't get a bug report on it for eight weeks. Now there are others where, for example, if the pipeline steps documentation disappears, because of a commit, that's an, for me, that one is critical, lots of users depend on it, we revert that thing in 24 hours or less, right, we revert that very, very quickly. So that was that was my thinking on it. And so I can share my own little bit of shame here. So when the, I went to add some updated logo images, and they weren't all exactly the same size. And now there, we figure that out. And again, Vandeet, thank you again for all of your work figuring this out. Wonderful. And yeah, but this is something that is visual and functional to that end. So again, is it affecting users so much that this isn't, this needs to be resolved immediately reverted immediately, or is it something that we can take the time to look into and figure out and understand and resolve, you know, in due time. So this one for me is more severe because of its perception potential perception by sponsors. Right. I would not want JFrog, who is a major contributor to the Jenkins project, or GitHub, a major contributor to feel that they were dwarfed by CloudBees just because we, we size the image wrong. So, so that that was the my concern on this one. I think this one is more severe than the other one. Again, it's, it's not an instantaneous, we must revert it, but rather this one has higher risk than that other one did. Right. And it's pretty, and a lot of that in this is the perspective, of course, in how that varies from each issue. And yeah, no, absolutely. So, Mark, and should we, should we revert anything right now or should we leave these be for the time being? Well, this one actually has a proposed fix from Vandit. So Vandit proposed a fix in another poll request. Oh, yep. And, and I think this one is the, I think this one is the fix. And so, so, but I would prefer to bring this one forward if we can, if we can confirm, yes, it really worked and maybe view the deployment. Kevin, let's look at it while we're here. Mm-hmm. Okay. So first we noticed that the jumbotron is not scrolling. Oh, yep. Okay. Now going onward. So that's not fixed. So that looks closer. Okay. Now could you change your window size? Oh, yeah. Just go to, go to a much smaller window or whatever, open in a new tab and... Hold on one second. Can you see my screen right now, Mark? Or is it not? You can see the GitHub issue for the time being but not the deployment. Okay. Yeah. Okay. Let me put this in here then. Okay. Yeah. Just, yeah, do a control plus multiple times and let's, okay, good. So it's not getting, it's not showing the CloudBees logo as enormous. Mm-hmm. So I think Vandit solution looks pretty good to me. It looks much, much better than what we had before. Yeah, definitely. It's nice and clean and everything's, yeah, similarly sized so that everyone feels equal. Okay. So, and I wanted to look at the actual code change because it may be that we just say we're going to, well, that was 5909. We're just going to go ahead and merge it because if it... Okay. So what he did is he just, he just restored the old images. Good. That looks fine for me. It works. Yep. Yeah. And I think, I know, I was trying to find higher resolution versions of the logos and add them in but forgot about the scaling. Well, and that's, that's the nature of these regressions in general, right? No shame in that. That's the nature of a regression is, oh, I missed something. Okay. I missed it. Not a big deal. We're not going to, not going to worry about it. Okay. So I just merged it. I said, hey, approved and merged. Oh, yep. There it is. Awesome. Thank you, Mark. Now, there's still a bigger picture challenge that Erwe noted in it of how do we do images in general? But that for me is a second question to be answered outside of fixing this regression. But I had a discussion with Erwe today also regarding images because each time I propose something with images, Erwe comes back saying, hey, I can do better. And he does better. Right. And he was thinking of something to automate, you know, when you make a PR for Jenkins IO, which would look at the images and propose a new version of the images, which would be compressed by a tool, whatever, and recite before compressing, which I tend to forget. You know that, Mark. Me too, Bruno. It's okay. Me too. All right. Then we're all in the same boat. Good. Yeah. So that's, progression handling is definitely going to be better when we can sit down and look at them and revert when needed and address everything appropriately. And this just helps us have those conversations and discover more of these little nuances that we can expand upon and make things better by. So, great. So now the open question, one of the questions that was open for me was how long should we wait before we revert? We talked about if it's a, if it's that somehow it should be matched to the severity of the problem. Any guidance there on how do we match that? You know, is it, I'm open for suggestions. Yeah. And is there, is there a way that we could create a label, maybe for someone to add saying high severity, low severity, something like that? That's a good, that's a good idea. Actually, well, and one of the labels we don't have right now is regression. Oh, okay. No. Yeah. Right. I think we've got, we've got a regression, an issue called bug. We've got a label called bug, but I don't see one that specifically says regression. Maybe we ought to just admit we're going to create a regression label. Because certainly regressions are bugs, but there are plenty of times when the bug is not a real regress, is not a regression, something that was never right. And I mean, go ahead, Kevin. Sorry. Just really quickly. I was just going to say, like, even if it's not a higher or low severity thing, as long as it says regression, it's something that could be flagged that we have to look at. So, but okay. Okay. Now, now maybe we ought to go back to Jenkins Core because they have two concepts. They have major bug and bug. Maybe we say major regression and regression. Would that already be enough for us? So let me see if I can find the labels on core. And Bruno, while Mark's finding those, I cut you off earlier. Yeah, no problem, Kevin. I was just thinking out loud. Would it be possible to add a GitHub action of some sort or something else that would propose to revert in a certain amount of time when it's tagged with regression or major regression? You know, even if it doesn't revert by itself, just, I don't know, put a comment somewhere saying we have to close that before that time frame that, you know, am I making myself clear enough to be understood or not at all? Yeah. Yeah. So, yeah, I assume it's possible. I just have no idea how to do it. Yeah, neither do I. But maybe ever the king of automation could have a look at that. So I do see in the labels, I see major bug, major RFE, bug and RFE on Jenkins Core. And they have regression-fix. So maybe we should adopt the same thing and say they're not using, Jenkins Core does not use GitHub issues to track. And therefore, we might want to say regression as a label and then regression-fix as a label to use their labeling as a way to tell people what's happening. What do you think? No, I guess I have an idea. Sorry, I'm talking non-stop now. Major regression for me was a chance to say, we need this resolved within 24 hours or less. That's a serious problem. Regression is everything else and we get flexibility there. Yeah, that makes sense. So if the two of you are okay with that, I'll just go ahead and create the label. Yeah, go ahead. Go with me. Thank you. Thanks very much, Mark. Okay. So new label, regression-fix resolves, a regression. So regression-fix has been created. And then are you okay with the idea of regression and major regression? I am. Yeah, I think that makes sense. Bruno, I like your idea. A lot of having the GitHub action, maybe you're saying you just have it like comment in the ticket or something to say like, hey, this needs to be reverted by this time because it's marked major or something. Right. Okay, good. So regression and major regression lost significant capability or major or important content. Could we make use of it just right now as we have at least one, which is? Yes, absolutely. In fact, we've got more than one. Oh, okay. Oh, rats. I just put the labels on the wrong place. Shame on me. Oh, shame on me. Delete. Sorry about that. Major regression and regression. I should not have done that. I have permissions that caused delete. My mistake. Okay. That was shameful. Well, that won't go real well. Oh, sorry. I just made the change to the Jenkins core repository that I intended to make to write. Okay. So the three labels were major. Major. Right. Okay. So I think I got the things that I mistakenly created fixed. Now let's do new label. All right. So major regression, significant, significant loss of content or functionality on the site. Okay. Major regression. New label has been created regression. Loss of content or functionality on the site. Okay. And then regression fix was the one that that one's already in there. If I'm not mistaken, Mark, because I can see that one here. Yeah. Oh, good. Okay. Oh, very good. Okay. All right. Okay. Good. So now that's there. I can just go into the doctor. Yeah. And that one is again, I think it's this one even is just a regression. It's not a major regression. Right? This is not one where we say we've got to roll it back immediately. Right. And the other one's been fixed by virtue of reset of merging that pull request. So that one's also that actually. Oh, right. Good. Okay. Yep. Okay. Was it major regression or regression major? Major regression. Yeah. But, but nonetheless, we don't want to use it for that. Yeah. No, no, no. Yeah. Of course. I just wanted to put them in here at least. We are coming up on time. So I would like to just kind of move through the next couple items here. Mostly just some pull requests that have come through recently. This one here is an update to or adding the updating Jenkins section. This one is actually also from Vandit. So thank you again to Vandit for all the work. This is a lot of content to add, update and review. So this will take a little bit longer and we do need to take our time with this, make sure everything's correct, verified and ready to go to be put into this section. Updating Jenkins is a very, very important action and process to take and having guides and information that will help users to perform those actions is amazing and goes a long way. Vandit's already added his author file. Kristen, others have commented on here for updating and reviewing. If there's anything that anyone would like to add or find out more about what we're doing here, by all means, check it out, share, interact if you want to submit a feed review or comment by all means. The second one here is a new reverse proxy edition. It's for light TTPD. Something more simple or not as much content but needs to be tested and verified before adding, if you feel like joining in and doing any testing by all means. And then finally, there is the idea of uninstalling a plugin from Docker. So this right now is currently being documented in the Docker repository. So this is not part of the Jenkins documentation just yet but is super useful and the information is relevant across the board. So we'll most likely be added once it's properly documented here. I'm trying to help with this one but I'm having some problems with the existing documentation, using the Java client, the list of comments that were available aren't all available these days. For example, you can't remove a plugin with a Java client these days or maybe you come on these hidden whatever. It doesn't work. I'm wondering what to do. I think the answer, it doesn't exist, right? I wasn't sure so were there indications that it's someday that in the past it did exist? I don't know the documentation was written. This was existing so I suppose at one time it existed but I have no proof. I just don't know. That was me is I know what I see in my Jenkins installation and my Jenkins installation definitely does not have that command. Okay, I was wondering maybe because I'm using the weekly release, the very latest one, maybe just disappeared at some time but no, it just never ever existed. And that I don't know. Okay, we'll have to find out. Yeah and anyone else who wants to check in, share input, try some stuff out, do some testing, whatever have you, ultimately you're welcome to. This is a community project as always. So great and yeah, this might be something we need to talk to the Docker experts about so if that's the case we will do so. Outside of that, it's being addressed and then investigated and Bruno's already done a bunch of work on there so we'll see what happens. Outside of that, I don't think we're going to get to the Using Agents page today which is fine. We'll just ignore that for the time being and I want to make sure we end on time. So that being said, thank you all for coming and participating and sharing here. I really appreciate it and I hope that everyone has had a wonderful start to their new year and just continuing all the prosperity that we've had in the last few months. So thank you as always and this recording will be available in 24 to 48 hours. Take care.