 Welcome, this is Jenkins documentation office hours. It's June the 22nd, 2023. Topics on the agenda, blog posts, Google Summer of Code. That one can be deleted. Change log for 20.401.2. Poll request from Jeffrey Chen. That we should talk to more. Update CLI for Jenkins documentation. Do you want that one on the list, Bruno? If you don't mind, just a few minutes. Great. Discussion and review of Java 11 to Java 17 changes in the documentation. This one, I think I would delay one week until Kevin's available. And then DevOps World Tour. That one, I'm gonna just drop from the list for now because I don't think there's much we've got to say here. And releasing a plugin, this is one I'd proposed that Bruno and I have been collaborating on a particular plugin. Maybe it's worth us doing a session here where we do a release of the plugin. Show the steps that are required and why. Anything else that we need on the agenda? I don't think so. Okay. So let's talk to, why don't you give us the highlights of the main newsletter? I don't know if I remember correctly. All that was addressed, but of course, there is a big part about for a platform documentation, everything like, but I just don't remember the highlights. Maybe just have a look at the key takeaways. Why would I add? So yes, plugins updates to fix a security from our realties on May the 16th. GDK8 finally has been dropped in favor of GDK11 for the running Jenkins agent. At least it's been, what, a year or so? Yeah, cool. And SSH agent has released a 5.00 now in art 5.5.0 and there has been some breaking changes related to the old pine version, I guess. So if you're using that, you'd better have a look at the documentation at the change log. Okay. Anything else, Mark, because I just don't remember. Those were the things that I think those are fine. The rest are covered. We've got the governance topic had some things in terms of prototype JS being removed and HTML3, HTMLUnit3 and Guava32. And we continue. Let's see, on UIUX prototype and accessibility. And those are cool things. And then end of life is coming for some operating systems. And this is warning users about it. And on we go. Yes, a major subject, I may say. Prototype.js removal is pretty a big thing. And of course, the deprecated operating system is also another big thing. So big changes are happening right now in Jenkins. That's cool. Thanks a lot, Mark. Okay. So removing deprecated plugins with Docker. So this is a new blog post from you, Bruno. And so tell us about the challenges hiding here and what you learned from it, et cetera. You know, intuition is not always helping. I thought I knew how to get rid of deprecated plugins just by following what was in the UI and I was wrong. Plenty wrong. So I took some time and wrote a too long didn't read section so that people who are in a hurry have the correct, at least I guess, I hope. I have a way of getting rid of deprecated plugins when using Docker. And then I detail the intuitive way, at least my intuitive way of trying to get rid of Docker plugins and why it fails. So if you are courageous enough to read that up to the end, you'll see that the progress makes sense until the end when you see it's not right, it just doesn't work. And I explain, I try to explain why it doesn't work. It's just because you are trying to work against the flow like a salmon in the river and why you should begin to remove everything from the Docker context first of all and then work with the UI. That was quite a lot of fun to write an experiment and now I feel just a little less dumb about plugins in Jenkins. I hope it will help somebody and I hope it will work outside of my machine. We'll see. Interesting, thank you. Okay, so what you did, so the in your too long, do not read. So in your summary, the message was, okay, build the container image that does not include your deprecated plugins. Then start it, but with this force recreate. Yeah, I should maybe have explained this one because I think it gets read, let me know if I'm wrong, but I think it gets rid of all the volumes in use or something like that. Or I just can't remember why. Oh, I think I should we try and maybe make another article about that one. Do you have any hint about why? I don't, I'm not nearly as fluent in Docker composes as I should be. So I would have to go exploring. I'm sincerely apologize, but I don't know. So either I should know because I wrote the article but I can't remember why, sorry. Okay, well, so it's worth investigating and but the steps that you've described here work for you. And so others can use those same steps. Hopefully. Great, okay. And in this case, what you were doing was your example was you were removing one of the deprecated plug-ins. Yes, there was Popper.js, which was needed by Bootstrap for API. And that's the one I wanted to get rid of first of all. Okay, good. I like this because that force recreate may be the crucial thing for me to learn more about Docker compose. Thanks. Any other highlights that you want to note on this particular blog post? Oh, no, no, thank you. I hope it's readable. Okay, great. All right, then on Google Summer of Code, so Vandit Singh's preview site is available now that shows this is one way that Jenkins documentation might look when hosted under Antora. Looking here's the version number choice that here are the version number choices and different components that can be selected at those different version numbers. So this is just a prototype, but the prototype is, at least for me, quite interesting. It is. So he's got the concept of user documentation and it's versioned. And then separately version, the developer documentation, and tutorials seem to use the same version. I'm not sure tutorials are as fluid right now given how it moved around, but it looks promising. Indeed. Cool, okay. And Ashutosh's work on Docker compose, this is direct impact on documentation. Anything you want to share there, Bruno? We're progressing on the automation of all the things because there were also still something that had to be entered by hand, and that was not really beautiful. It's not the goal. The goal is to simplify as much as you can the existing documentation about Docker by providing example that work out of the box. And it would not really is the case, but now from this week on, we have a working example fully automated, just one shell file to launch and you're good to go. And hopefully we will have other, more meaningful examples in the weeks to come. We'll see. First time being it has proved working on Linux, WSL2, macOS, and Gitpod. Woo-hoo. Ah, okay, so WSL, you said Linux, WSL, Gitpod. What was the other one that I missed? MacOS, MacOS. Oh, and macOS, okay. And is there a place where I could go to see this or where others could go to see it? Yes, of course. It's a work in progress, I will give you the link of the repo. There we go. Can I put that in the chat? Yes. Okay, so here it is. And I'm just going to paste that URL into the notes. Great. Okay, so I could go grab from that if I feel like working something with Docker Compose and experiment with it. Yep, for sure. Very good. Excellent. Okay, good. Then the other two Google Summer of Code projects really don't have documentation impact, so I'm just going to take that note out. Anything else on Google Summer of Code? No, thank you. Okay, so 2.401.2 change log. Kevin noted in his preparation of the notes that it's been prepared and merged. And I think it was quite simple. It's got just the one item that says, hey, we're warned administrators when their Linux operating system is approaching end of life. And next week, Chris Stern is the release lead and thanks in advance to Chris for his efforts on that. Great. Anything else on 2.401.2? No, Mark, it sounds promising. You will see. Okay. Next one then is Jeffrey Chen. We had two, a week or two ago, been looking at this pull request 6409 from Jeffrey. I got working on it over the weekend and found that it just wasn't working for me, so I split it into two. Oh, okay. I couldn't push back to his branch, and so I split. And the split went to this one, convert the administering page, and to this one, which is add a best practices page. And I think let's take a look to see if they've got feedback on either of them that say we need to block this thing. Okay, so Kevin's given his. So it looks like we don't have approval yet, but the changes have died down. So it's time for me to go do another visit of this one. That's a lot of work, but that would be a good thing when it will be finally merged into the right place. Yeah, so let's make a note. Replacement pull requests, PR dash, okay, 6477, okay. And I think the next one was probably 78. 6478, yeah. Yes, okay, good, so. 6478. Down, almost there. Fine, whatever. Okay, copy link. Okay. All right, so and what these are is this one was administering, and this one was pipeline best practices. And part of me is worried that pipeline best practices is a bold statement, so I want more reviews on it. This one I'm less worried about the technical accuracy because I'm reasonably experienced in this one. It's just talking about the Jenkins home directory and copy, rename and move projects, which is functionality Jenkins has had for a very long time, but has never documented that fact. So this one, this one I think given actually since we're here, why not let's just call it Kevin's feedback is resolved. I'm going to go ahead and just squash merge it after. We get the build successful. Okay. Ready to merge. This pipeline best practices needs more text. I inserted some placeholder text that said put more text here, but I haven't done the insertion of that text yet. All right. Anything else on that topic. No, thank you. Okay. So next item then was a draft pull request on update CLI. I assume Bruno, it's still draft. Oh, yes, indeed. It doesn't work yet. The thing is, I'm trying to replace all the references to Docker images and plug in versions in the documentation. And I had done things wrong. You know, I've just been discovering a better life for a few weeks now and I'm doing newcomers errors, of course. So I had a refactor recently and I stumbled onto limitations or bugs within update CLI. So I submitted two issues. I think yesterday to update CLI. And one of them has already been sold. And I hope to see a new release of update CLI soon so that I can get something better. And I also asked for some new features on update CLI to get things faster. You know, it works with sources and conditions and targets. And for some reasons I need, at the same time, Ruby and Alpine. Python and Alpine to compose a tag with the version of Ruby and the version of Alpine, for example. And I do that for several files and it's a waste of time because I need Alpine in most of the files. So I'd like the CLI to do something, you know, with the sources and keep them up to date for all five that it will process, for example. But yes, it's still progressing. And for some of the documentation, the committee removed the pinned versions of the documentation for very valid reasons. But I put them back. Oh, good. Okay. Yes, I'm afraid I did that after you mark. I'm sorry. It's just a proposal. You always can say no. No, no, no. Well, what you did, the adding the pinned versions is much, much better behavior. I was just too lazy to update them. So good for you that I wasn't willing to update them. Update CLI would update, automate the updates. Yes, but no, you were not lazy. It's a pain in the neck to do. Okay. Yes, I was unwilling to do the work necessary to update them interactively. I felt your pain when reading your PR. How can it do such boring work? I have to do something about it anyway. And it doesn't work for the time being just because the pinned versions are not in the master branch. They've been removed. So my update CLI check doesn't work. But that's not a mandatory step. So whenever we merge it, that should be fine. But it's not ready yet. Sorry about that. I am still waiting for a new versions of update CLI to get it to work perfectly. Well, and I think that's a great thing, right? To be able to use tooling to automate this and tooling we already use elsewhere to do automation. Great. Yes. I went even too far. For example, I started to modify a blog post from 2017. No, this makes no sense. Let them like they are. It's perfectly fine. Good. All right. Anything else, anything else on your use of update CLI? No, thank you, Mark. Okay. So next topic was Java 11 to Java 17 upgrade changes. This one let's link to the pull request because Kevin has created a draft pull request that we can, we can reference. And the draft pull request. Has already a few notes in it in terms of. What, what we have to do. Yeah, here's the draft pull request. But it's, there's an awful lot yet to do and there are some complications hiding in their draft pull request. So for example, if I remember right when I started on it. I saw things in all sorts of places related to Java 17. Like Kevin did. Maybe there is even another link where we had a checklist. I don't see it here. Oh, this one. In the issue. There is a description of. Checklist items that Kevin and I identified initially. These are the things we knew needed to be changed. But then there are many more that needed as well. Let's open them just to give ourselves a hint. Okay. So this one. Jenkins running Jenkins on Java 11 in Docker. We probably want to just replace that with running Jenkins on in Docker. Because we'll, we'll, we'd prefer they use Java 17 and we'll tell them to use Java 17. Those kind of things. All right. Anything else on Java 11 to Java 17. I don't think you know. Okay. Next topic was releasing a plugin. All right. So Bruno and I have our, have been contributing to, oh dear Bruno, which plugin was it? It was, oh, HTTP request. Right. I think so. Yes. Okay. So let's go to the HTTP request plugin. And here what we see is that. We had a pull request from. Christoph Bexer. Christoph. Oh, Bexer. Oh, Bexer. Yeah. Right. Proposing a new feature. And Bruno and I reviewed it. It looked good. It's got documentation. It's been merged. And with that merge, we now see in the release drafter. Well, quite a number of things that have been, have been collected since August of 2022 when, when this, the last release was done of this plugin. It's got lots of component updates, right? The upgrade to HTML unit three. It removes some old junk from jelly files. It improves a number of things in documentation. Fixes one bug. Let's look at that bug just to be sure. Okay. And then it has three new features. One of which is required Java 11 and Jenkins 2.361.4. It's a reasonably significant release. So our idea here is let's do this release today. And nothing is marked as breaking change. Right. Even if somehow there must be some hiding. Well, we, we hope not, but. All right. So Java minus version. So what I was going to do, let's make the text bigger. Yeah. Because bigger text is easier to read. Is that easy enough? Yes. Even without the glasses. Very good. Okay. All right. So the release process that we want to use, and it's documented here. Let's go to the Jenkins documentation. Releasing a plugin. Releasing a plugin. Releasing a plugin. Plug in. These tips of performing a program plugin release manually, because this is the one we're going to do manually. All right. So it talks about. How to configure and I've already configured myself. And now it says this is how we perform the release. Maven. So I checked to be sure that I can push. And then Maven release, prepare and release perform. So that's the step we want to do now before I run that. I like to know that I'm running the right version. And so I'm running Java 11. And latest Maven 3.9.2. And I like to clean my repository. That's a stupid question Mark, but I haven't seen that in the documentation. Is it written somewhere that we have to use Java 11 and Maven 3.9.2. It's not because the version of Java that someone chooses depends on their, on their preferences. Of course. So us mandating, you need to use. Well, it depends on the, on the plugin itself. This plugin, because it now requires. Java 11 would have to be released with at least Java 11. I could do the release with Java 17 and it would generate Java 11 bytecode. But I'm a conservative and I like to generate releases with the same Java version that I've been testing with. Of course. So this is where there is the change from Kristoff. And there are the other changes that happened. So if we look further down, we'll see the last release was here. So now it's time for us to try a release. And that is, well, let's go copy the text, copy paste. So it's offering the, it's asking me the question interactively, what version do I want to release? And I'm going to open up my page that was telling me what version, this is the page we were looking at. The draft is 1.17. So that's the right version. This is generated by release drafter automatically. So because release drafters configured, we'll use 1.17. And that tag. Now let's check some remark to interrupt. That's because it. Guest that there was nothing major that would have a necessity. A bigger, you know, not a major update or whatever. It's just a new version. Yeah, to be, to be precise, what it does is it reads the palm file that has this number in it. And so that's, that's great. We're going to say the next version we won that 18 snapshot. And now it's going to start the build. And this will run all the tests. And once the tests have passed, it will then publish the build. It actually runs the build in two steps. That's what release colon prepare was that prompting phase. And then it runs this set of tests. And then I believe release colon perform. We'll do another build without running tests. And then we'll push. The, the changes to the central repository to repo. Jenkins CI.org. Okay. So there may be a build with debug. Information and maybe something without debug release. I don't think that's what they do, but I'm not sure. And again, I don't know the details of Maven release process. It's good enough for me that this process works. Now, while it's running, let's go look at. At the instructions. Okay. Some of the things that might fail. We could get a failure to upload. Right. And that might have been might happen in this case. We may see that because I requested permission to perform that upload. It might be a few hours ago, but if we were too fast, it might be that the permissions have actually not been granted yet. So if we look at, at that poll request, let's go look at the poll request. I submitted to repository permissions updater. This is where I submitted a request. Please let me become a maintainer of the HTTP request plugin. And so here was my request. And we see that. Tim merged it three hours ago. And our hope is that three hours is enough that all of the permission changes that this. Repository permissions updater applies have been applied throughout the whole system. Okay. I thought you were already maintainable for this plugin, but well, you official adopter. There's no, there's a difference. And that's, that's an interesting one, right? Because you and I both have permissions on the GitHub repository. Yep. And we have those permissions. However, some months ago I had revoked our release permissions. By submitting this poll request that says, Hey, stop these people from releasing plugins. It didn't revoke our GitHub permissions. All it did was revoke our permissions to release. So we were still allowed to contribute to the plugins still allowed to merge poll requests, help it along. But what we couldn't do was deliver a new release. Okay, which was very reasonable. Yeah. Right. And so this, what this poll request that's on screen now is doing is, it's reverting a small part of this poll request. Yeah. And then I may still go back eventually and say, I'm not really ready to stay on as a, an HTTP request. Maintainer, but this particular. This particular release feels like it's a worthwhile release. Right. Upgrade to Java 11. Add a new method. Add credential, credential tracking, which I like a lot because it helps me know which jobs are using a particular credential. So, so we hope that this is all positive for its consumers. Yeah. And now let's see how the build's going. Oh, it's finished. Okay. So what we see here is uploaded to repo to Maven. Jenkins CI dot org to this location. And so here is the data. Here is the plugin. And if I open that page in my web browser, we can actually go look at it and see now really people shouldn't bother browsing the artifact repository like this. But there it is. Not exciting. Yeah. Now the release itself won't appear. It takes from minutes to as much as an hour or two for it to become visible in the Jenkins update center. So if we go to updates dot Jenkins dot IO. Here we can see there's a link that says latest releases of Jenkins war and all plugins. So let's open that page. And now here if we go to HTTP request. And now I'm going to do a little bit of a cheat. If I click this, it will download it for me, but I don't want to download it. I want the link because I'm going to use it to query the mirrors. So if I do this and do a question mark mirror list. This will ask. Update center to give me the list of mirrors and the version. So right now the version is still one dot 16. And we can see that it's it's available on. Eight different mirrors. But what we released was one dot 17. So while we're waiting for the mirrors to get it, we need to go publish the changelog. And that's a that's that's a manual step for this thing because this thing hasn't been configured. Oh, you said that was my next question. Should appear all by itself automatically within GitHub. And the answer is it won't. So what did appear automatically was not the tag one dot 17 has appeared here. That's good. Right. That's the tag that was created by Maven release prepare and release perform. And this is letting me use that page that already existed. So I'm going to go ahead and publish it as the release. So the release is now published and now other users can see that release on the GitHub page. And plugins dot Jenkins dot IO over the course of the next four to eight hours will detect this release as well. And we'll insert the documentation from this release on to its page. So if we go to plugins dot Jenkins dot IO for right now. We will see that it's still showing one dot 16. So here one dot 16 is the most recent. And in a in and it's usually four to six hours, maybe as much as eight one dot 17 will become visible there. Well, that's cool. And that concludes the demonstration. Oh, I've got one more to do. Yeah, thanks a lot for sharing that with me. I'm pretty happy to witness that live. All right, well, thank you everybody. That's all for today for Docs office hours. Recording will be available in about 24 hours. Thanks.