 Welcome. This is the 2nd of June 2023. It's documentation office hours. Thanks for joining. Topics that I'd put on the agenda 2.401.1 released. 2.401.2 release is in four weeks. Chris is the release lead. Yep. Is it two weeks or four weeks? It should, so release candidate is in two weeks. Yeah. Okay. So I just got them confused because I have to get the drop set on me in two weeks. Right. Exactly. So Doc's team needs to create the change log and upgrade guide for 2.401.2. Internationalization poll request, end of life notifications and main newsletters. So Ashutosh with you here and with Chris here, are there other topics you'd like to add to the agenda? Yep. She's Doc. Okay. Google summer of code. Yeah. Cause like two projects are like directly related to Docs. All right. And so we've got the, we've got the Docker quick start. Yep. Project. And we've got the alternative build process. And no, let's call it what it is. Versioned documentation for the Jenkins handbook. Yep. User handbook. Okay. So any other topics you want to add? Google summer of code and Ashutosh, this is yours if I remember correctly, isn't it? Yes. All right. So let's talk to that one. That seems like, and if there are conversations we need on version documentation, we can certainly have them. Otherwise, I think we've got a meeting scheduled in 12 hours or so. Yeah, we do. Okay. Any other topics that need to be on the agenda? Okay. Then let's take this one first. So Ashutosh, do you have questions or do you have topics you'd like to discuss? Not right now. Bruno just recommended me to attend the office hours for docs to get familiar with the team and how things work here. Okay, great. And are you comfortable with the places where we're currently using Docker in the Jenkins documentation and some of the terrible flaws of that? Yes, I'm familiar with the documentation. Okay, great. Super. All right. Well, we're happy to have you here and look forward to your contributions. So I am curious, how's your experience been in trying to use Docker compose to make an easier way to set up Jenkins and its agents? What's your experience been so far? For the first Docker compose file, we decided to go with a simpler file for battery beginner user experience. So I'm building a first Docker file right now. That's this on this week's bucket list. And I'm getting some errors and they are getting fixed. So I'm working towards it. First file Docker compose file will be completed by end of this week, I think. Oh, good. All right. So would you like to show us a demonstration of the compose file? I would love to see it if you're willing to share it or point us to a repository so we could look at it and talk about it. Yeah, we'd like to see it too. Very good. I'll share the link in the chat. All right, thank you. I'm not a compose expert and therefore forgive me using you as an education as a point of education. No, I'm not that experienced either. OK, so. Yeah, and this is the experimental repo for the project. Perfect. OK, so using a modern version of compose and the Jenkins LTS version. Running as that seems dangerous. I'm a little surprised you're choosing that one. What motivated you to choose a route? No, this is for I was just experimenting. So I gave all the permissions. I was getting some errors, especially with the SSH keys. I was using RSA first and this RSA was not working. So that's why I get the error and we used ED 25519. That solved the error for keys. But we still don't know why the RSA was not working with. Ah, OK, well, so in terms of documentation, I much prefer ED 25519 keys because there's there's so much shorter text. The document, the open SSH people say they're also more secure. OK, so so and now now the and you're doing privilege true for the same reason, I assume that, hey, while you were doing development work, you wanted to be sure that permissions didn't get in your way. Yes, yes, that's the reason. And now you've already got an agent configured. Does it actually work for you? Is this is this working successfully? Yes, and this one is working successfully. That's why I said all the things to route and privileged because of so I didn't get in my way. Great. And so just for experiments right now, yeah, absolutely. And and experiments, it's it's perfect that you're doing it this way. So this is the ED 25519 private key. And this is the public key. And here is your oh, this must be your RSA private key. Yes. OK, good. All right. Well, so and I can I I am no fan of RSA public keys because of that scroll bar. So thank you for using it 25519. That's a good choice. Yeah, but we recommended it to me, too. I was using RSA, but I was getting errors because of RSA. So he recommended it, too. Very good. And now this one is using. Oh, no, I see. I'm looking at the wrong file. Now, this is your your current one that's that you're experimenting with. We had seen its user root privilege true. And and before we go to production, I assume those will be gone. But we have to be sure we understand how how and what. Yes, Bruno also created a full request yesterday. I think it was eight hours ago. Good. OK. But this is he said there are a lot of things in it. So I have to look into it. I haven't looked into it right now. Oh, that's interesting. OK, so I I would I would have hoped we didn't have to do that. But then again, I'm not sure how the host key operates in that environment. These are just ideas. We haven't finalized it. Yeah, good for him. OK, so now and in terms of generating the compose files, are there specific techniques you use to make those to create those compose files? Are there are the tools that help with that? Right now, I don't know how Bruno created all these files because he opened the PR eight hours ago. So I haven't seen much about much what is happening in those files. OK, and now I've I apologize. I've lost myself. I'll just click that link again. Here we go back to the OK. All right, well, so this is this is already encouraging because it looks like what one of the problems that we have in the demonstrations in the in the the samples that we create is we end up running things on the Jenkins controller. And that's a bad that's a bad pattern. So what you've done here is already. Reached past that problem so that we could now set the Jenkins controller to have zero executors and only run things on this agent. Nice. All right, well, Ashutosh, thank you. Anything else you want to highlight in terms of of how your experiments are proceeding? Experiments are turning out fine. I was wondering how the process of setting the documentation will go. That's why Bruno recommended to attend the meeting. Plan was to just see if I get familiar with the team with the first meeting and discuss about documentation later when the Docker files are completed. OK, would you be OK if we spend a few minutes looking at the documentation together and talking about how how we might think it would it would change using a compose file? Yes, yes, of course. So so Chris and Meg, this is where you jump in and and give guidance as well because the things that I like about so the compose file is one way to solve this horrible, awful, terrible experience of installing. You never heard me say that. But the Docker install process here is let's see how many steps are in it, right? It's too many. You've got to you've got to do. Step one, open up a terminal, create a bridge network. What? OK, and then then you've got to do. Run this monster, terrible thing that turns on that does does the Docker in Docker. And then you've got to run this created Docker file that brings in the latest Jenkins LTS. And then you've got to build it and then you've got to run it. So we're already five horrible steps into this before you've even reached the post install wizard. OK. So my dream is that Ashutosh's work will replace those five horrible steps with one command. Docker compose up and the file name Ashutosh. I know that that's a long ways off for you and I'm OK with it being a long ways off, but that was my hope. Chris or Meg, do you have a different opinion on how we should how we should hope for this? Yeah, I agree with what you said. So it's a replacement of what we have for now. Good. All right. Meg, any guidance from you in terms of of ways that we should look for making this this experience better? Don't look like. Yeah, Meg, you're muted if you're saying anything. OK, she may be away there. No, I would just be there and then I couldn't find the microphone sitting here, swirling like a fool with my mouth. And then is it going to be a similar process for Windows? So the Windows, the Windows documentation today uses uses the Windows installer. OK, so that won't change based on what what Ashutosh is doing. But oh, maybe what you were asking was Docker on Windows. Is that what you were asking? Right. Yes, except for Max and Lenny. So I think so. And I think if if we are if we are as if we are as lucky as I hope we will be the Windows and Mac OS, the Windows, Linux and Mac OS will actually become a single thing. Ah, because you don't really have to be the only reason for the the differences between these is this exotic stuff with Docker and Docker. Right. And I am hopeful that Ashutosh in in investigating can find ways to to do that in a way that works with with containers on Windows and containers on Mac OS and Linux. Now, the assumption for me is that in each of those three platforms, the container is actually ultimately running a Linux variant inside the container. And that's the default way that Docker CE runs on Windows is it runs with Linux containers underneath. So so Ashutosh, does that sound OK to you? Or were you assuming that you would have to do something somehow with Windows based containers on Windows? No, I was also assuming that will be a single file for every opening system. Great. So the the the dream then, Meg, is that the on Mac OS and Linux section disappears and the on Windows section disappears. And it just becomes this is how you do it. This is how you do it. And it's a simple command Docker compose up and the the single file. Right. That'll be lovely. Yeah, that's the match that's supposed to be Docker. You can run this. It doesn't matter what operating system you're on. You get in it and right. Well, and in this, the thing we need here is and this is that's the thing that Ashutosh is doing for us is creating a multi container configuration. Right. So here's the agent container. Here's the controller container. And I suspect for tutorials, there will have to be somewhere in here a Docker and Docker container or something that gives Docker agents to the controller as a as though we're a cloud. And I don't know which of those it is. But yeah, that's that's the the likely destination we dream of. First step, I would love to get rid of this awful ugly things that are here. And then then we can consider going further from there. Great. Very nice work. I got some question about the Docker compose file prepared by Ashutosh. It's like I'm wondering if it's a good idea to put like like under Jenkins with start no as well. And also to add the size to it. Oh, so Chris, I missed that you're suggesting restart. So restart setting. Yeah, we start setting to set to no for the Jenkins controller. Oh, no, why would you set it to no? That's interesting. I thought that it was typical that for Docker, I had to set it to restart some other setting. Now I've got to go look and see what it was. But I remember that I've got a setting in mind that says something about restart. I just don't remember what the restart setting is. OK, we should look into it. OK, so here I've got let's see, looking just a minute. So in LTS with plugins and there is a Docker underscore run this one. OK, so some here how I said, oh, yeah. I set restart to on dash failure. Now that may be the wrong thing, but for me, it works. It lets me do a restart and then the controller comes up again inside. OK, maybe we should add this to it for now and test it. So Ashutosh, have you had any experience with a restart setting? No, I haven't. I don't have any experience right now. I look into it. OK, great. Good, good question. OK, and also how about S H M size? Just in case if it's not enough. But I think for this purpose, it should be the default, I think. I don't remember like the default was less than 5 GB. So if you want more than that, we have to add the S H M size. And so you said S H M size is S H M underscore size. S H M underscore size. OK, and I'm not setting that, so I must be OK with defaults. But that's a that's a setting that can be controlled in the in the service definition inside compose. Yeah. Well, that would that would certainly give us a better chance of assuring that Jenkins had at least a minimum. Now, is S H M underscore size defining the maximum value for it or the allocated value or I don't remember because I did I did search for it a while back. Let me see. S H M size. So that's that's basically just I think it's a max size of the dev slash dev slash as you can in document. OK, oh, and this is interesting. OK, so so S H M. Yeah, because like we wanted to some problems of it for get lab parking when we're doing the config for macOS. Ah, OK, so so this. So OK, so I'm not sure I guess I need to read the instructions. What S H M size is. OK, so Belena talks about it as interesting. OK, so needs more research. Ashutosh, you've got the good question. Any other questions, Chris? No, just those two. They follow. All right. Excellent. Ashutosh, congratulations on being accepted and thanks. Thanks in advance for your contributions. Good luck with your investigation. Thank you. Look forward to seeing the next stages. Exactly. Good work. All right. So let's see the questions we had were. Oh, I should embed the embed the link to Ashutosh's example because that way I could play with it later. OK, and then it was questions from Chris and Ashutosh of the recording of this session will be available on community.jankins.io roughly 24 hours after we've done the meeting. So you'll be able to refer back to it. Um, so it was should we set S H M underscore size needed it for GitLab plug-in, right? Yep. Modernization. So if the GitLab plug-in project. Because I always it would just drop like I mean that the instance we just dropped by itself after a while for my computer anyways. OK, and then the other was should we set restart? To and my question was, should it be to on dash failure? And yours was should be should be was it should it be on on failure or no? Yeah. And I don't I don't know which of those is most correct. I know that I've been very happy with on failure in my configuration. And then questions from me. And I think Ashutosh already answered those. It was should we have privileged through? Should we have? User well and route. And I think that the hoped answer, the way Ashutosh described it was the hope is no on neither of those. But for now, it's it's in his is his experiment is prototype. OK, great. Ashutosh, anything else you wanted to highlight there before we go on to other topics? No, nothing else. OK, all right. Chris, anything you want to note on the versioned documentation for the Jenkins user handbooks? Maybe we the thing is I think we should like start talking with Inva or Gavin about setting up about how to how to move forward with hosting. First draft of the work to dark star. Jack, so I know. So and so I was thinking we wanted some time before we would make it visible globally, but we would like a preview first. Would it be OK if we have need we need to have a preview site? Configured. So that we can see the site in action. And that may need coaching from. Gavin Mogan, good, all right. OK, or Jenkins Infra. And I think they may be able to help as well. But good, all right. Anything else on versioned documentation? I think we are about to have like something to show for in maybe next week. But so we'll report back next week. Oh, good. Yeah, because we're working on like moving to images manually because it cannot be automated according to Vending. OK, say that again. So what's what is the images? Because they have to move to the new structure. So it's like that then like all the other links would have to be updated one by one. And that could be like time consuming. So it may take a week. I see. OK, so and that's because of Antora's different way of handling images or? I think because, yeah, and I think it's for Antora. Like the way that the images are stored may be a little bit different because like right now it's it's more centralized, but maybe in the future. So it's depending on the module, I'm not sure. OK, I'll need to take a look at Vending to find out. Great. All right. Thank you. OK. Anything else on that topic? No. All right, next topic then was the 2.401.1 change log and upgrade guide, and that's visible here. So here is the change log. And here is the upgrade guide. Oh, and and there are two mistakes that we detected. I should note that that's good. Mark made two mistakes in assembling the change log that we detected while we were doing the presentation of the what's new in in 2.401.1 to at least two items were already delivered in earlier releases. So I'll get those removed. Any questions or concerns on the LTS process or the the content of the of the documents? OK, and so for 2.401.2, it'll probably be me creating it, but Kevin may be back in time to do do a revision of it. So Kevin returns returns June 12. He may be able to oops. Let's put that in the correct location. Oops, Kevin returns June 12. May be able to do the change log. Anything else on those topics? No, good work. OK, next one is a victory. This pull request from Jeffrey Chen came in two weeks ago or so. And what Jeffrey did was he brought back a stalled pull request that was originally proposing to take content from the internationalization instructions on the Wiki page. And this is something that was done all the way back in 2019. It was started. We did long series of conversations about it. Meg, many others have been involved. And we then said, hey, this is stalled. We're going to move it to stalled so it's not distracting us. Jeffrey Chen brought it back. What he brought back, though, was. Incomplete or not quite what I thought we should do. So I proposed some alterations to it. Jeffrey accepted the alterations and we ultimately deployed it as. Let's look at the page and now here. So here we've got first pieces that internationalization internationalization and localization is no longer work in progress. This is good enough. It's production. All right. Developer tasks, translator tasks, both relatively short lists and entry for Chinese localization still. And pointer to how to configure IntelliJ to make your job easier doing localization. With links inside the page to more details, then right next to it on the page is the crowding integration that Alex Brandis has helped configure and makes it much, much easier to translate plug-in text from one language to another. So thanks to Jeffrey. Now, Jeffrey has continued and has made the next step, which is another poll request. And the next poll request will probably need the same kind of work on it. It's this conversion of administering Jenkins and Jenkins best practices. And the challenge here is that many of these things are already covered elsewhere. And we have to find the correct locations in the documentation to put them. And I'm not sure that Jeffrey is able to to do that. So so this really will require more, more work from from those of us who have got some deep experience with Jenkins and its documentation. Yeah. Meg, is this one you want to take a look at it and document or add some comments on? I would. Yeah, I will definitely be interested in reviewing this one. Okay, I'm going to add you to it so that that way you know you can see it. Okay. No need to feel like it's obligable that you're obligated to do it. But if you've got capacity to do it, this would be a great one. This would be a great one. Bruno has gone through and made linguistic changes and style changes to to bring things up to our common way of doing things. And Jeffrey has already applied those changes. So what you're seeing should be already first level first draft. Good enough to review. OK. And let's put a link to that one inside the. OK. So and let me the point of this is to get any useful information from the Wiki merged into the existing docs. Right. Right. The goal is to to take the content that's being proposed here and find the best homes for it. OK. And that's that's a structural question, not not as much a content question. Right. It's OK. We read the text and the text says this and then we have to decide do we already have something that says this? And if not, where should this be put? Because I don't think we want a new page called administering Jenkins. No. Right. We've already got plenty of pages like that. So and and I suspect we don't want. J N D I environment entry. So so there there's some things in here that are just flawed and discover those as we're working. OK. But we're not going to talk about whether the split between management and administration is always saying, et cetera, that's beyond the scope of this. Right. Well, it's what what I was thinking is let's find the right place to put this kind of content if it doesn't already exist. And if if you feel like it belongs in managing or administering, I'm fine with that admitting that we know that the distinction between those two is flawed and imperfect, right? I mean, managing Jenkins. Why is admin? Why is there a managing Jenkins page and then a system administration or a section? And then so, yeah, the those things are. Not terribly logical. Right. But it's always a problem because life. Oh, wonderful, though. This should be good. Yeah. So well, it's it's worth it's worth at least. I think I think there is much to be done, much value to be gained here by going through it and identifying every every one of us who sweeps through this will find things that we can improve, things that we can do to make it better. Great. Great. Anything else on that? That poll request from Jeffrey Chen. No, that's good. No. All right. Then the next item I had was end of life notifications in Jenkins core. So this one is we've got a with beginning with Jenkins two dot four hundred seven. We've got a warning that appears to users now if they are running on an operating system that will be end of life in the next six months. What that mean? What, Meg? Oh, I was just saying, yay. Yes, exactly. So if it also announces an early end of life for Red Hat, Red Hat Enterprise Linux seven and its derivatives like CentOS seven. So that early end of life is because that thing is such a pain to support that we want to get it out of the Jenkins project sooner as soon as we can. Yeah. Now, we've got the next step on this and the next step hasn't started yet, but it will be coming, which is container end of life. So this was operating system end of life. But we also have a problem that we need to be able to say container end of life. Oh, yeah. Where what we've got is, for instance, there are some containers that we've got some containers that are done with Arch Linux. It's a low volume distribution. We don't have anyone in the maintaining team that's interested in it, so it's not being maintained. And therefore, it's it doesn't make any sense for us to retain it. But we need to in some way find a way to announce to the users, hey, you're using a container that we're going to stop updating or we've stopped updating. The other kind is this one has already covered CentOS seven controllers. A controller container or yeah, these are containers. So controllers and this one is already showing the end of life warning because it's using CentOS seven. OK. But we've got others, for instance, Alma Linux eight. That we think we want to end of life. And one way to do it is to declare the end of life and make it visible and tell people your migration path is to this other operating system. Yeah. Or to this other container image. Any questions on that one? No. All right. This may be a dumb question. So off the top of my head, is there going to be any attempt to record this historically? No, because we do end of life anyhow. This is just we're warning them, right? With some people, someone a year from now comes in and wants to know what happened, you know, what the path was out of CentOS seven or something like that. So we don't do that, right? We don't need to do that. Well, actually, good, good question. So as you're thinking about, so we're we're pointing people to this blog post for right now so that they have a reference to the dates and the and the plan. I've wondered should we have an end of life table in the Jenkins documentation somewhere, eventually, but I wasn't sure that that would be as helpful as. As as the version documentation, which will give us a place that we can describe which platforms we tested with a specific version anyway, right? Except that some some because. Unfortunately, users do not upgrade when we think they should. Right. Some like a little bit. And every once in a while, somebody comes out of the woodwork who was just, you know, 15 versions behind. Or something. I don't know because the table would also be kind. I don't know would it be a pain to maintain or maybe not because once it's dead, it's dead in that stage, you just become keep adding stuff, right? Well, and maybe this is something this is a topic to discuss with Chris. So certainly today we have let me describe what we have today. So today I'm going to play note it this way, Meg. Should we document the tested. Operating systems at Jenkins release, right? So in the version documentation, should we we note the operating systems that were run through automated tests? So in the packaging repository today, tests container can test installs of all sorts of operating systems, Fedora, 37, let's see, Red Hat 8, Red Hat 9, Debian 10 and maybe what we want is some way of of declaring. Hey, here are the things that were tested so that when we have version documentation, we see that 2.401.1 was tested with this mix of operating systems. Chris, what do you think as a as release lead? Could you envision something like that or? Yeah, I do. Because I think it's kind of like what it's a based on version of Java we're using for Jenkins is similar in nature. So I think we should document it properly. Right, right. Yeah, and it's even Java versions, right? Because it's hey, we're using 11 this and 17 this. And we also ran tests with 19 this. Yeah, right. Good, interesting. OK, good, interesting concept, Meg. I'm not entirely sure how to do it, but we've got something like it already in. Well, let me show this page because I was just checking it today. In the Jenkins documentation, we have a page called choosing the version, a Jenkins version to build against. So this is guidance to a developer of what value they should set for their Jenkins version in their palm file. Right. And it tells them 2.375.4 or 2.387.3. Now, five days ago, those numbers were 2.361.4 and 2.375.4. This documentation knows when we release a new LTS and puts the latest LTS there, one back there and two back there. So something like that, we could probably extract the tested operating systems from the packaging repository as well. Yeah, good idea. If somebody wants to know what it was a couple of releases ago, they can go back to those other release notes. Exactly. You don't have to give them a single historical textbook on the whole thing. Mm-hmm, right. Of course, see, I want the textbook, but I wouldn't know that. I don't know that I'd want to have to write it and maintain it. Well, and that's the thing that I'm not especially interested in putting this kind of information or the operating system to be tested into the changelog, right? Because for me, that's different than the features in the release. But I guess we could consider putting it in the changelog instead. It just, for me, that feels like not of interest to most people. They want it on one platform and theirs. Good. OK. Did that answer your question, Meg? Yeah. It'd be interesting to mention this to some of the other maintainers and stuff, see what they think about it, what they hear from. Because I'm sure if they get called into the crazy cases where somebody's like three years behind, they haven't upgraded for three years and now they want to know what to do. Right. Right. Good. OK. Yeah. All right. Anything else? Any other questions or topics? I've got one last item and then we can close. Cool. Hey, the main newsletter, I've got to do some writing for it. And onward we'll go. OK. I've got a question for Ashutosh. Have you guys, like, for the project, for Gizok project, for Docker Quickstart, have you guys planned how to draft the documentation needed for the Docker complex examples? Can you predict? I don't understand it. Have you planned, like, how to draft the background details? So it's like, is there, like, any processing place? Like, how do you review the, like, on top of the Docker compose files? So you also have for the documentation you have on Jenkins.io. So some passages, too. So, Chris, let me test to see if I think, if I understand. I think what you're referring to is something like this, where the lines in the compose file or the lines in the compose file itself have little bubbles that tell us this means this. Is that what you're saying? It could be. Yeah, it could be. And also, it's like, I'm just wondering if they have a process, like, so Ashutosh can start, like, drafting. No, we, right now, we haven't had discussed anything like this. OK, OK. Cool. I'll check back later. Well, and so the idea that the compose, for me, the ideal that the compose file would be self-documenting is really, really helpful. But the challenge with self-documenting in the compose file is then it becomes mostly comments. I don't mean to document in the compose file. It's just to document it for Jenkins.io. Because, like, we're not just using the Docker compose file, for example. So there's, like, there's some background information behind it, too. And those, like, Ashutosh may want to collect as he goes along, and he may not want to wait until the last minute to do it, because then he may have forgotten, like, most of the details. That's what I'm asking now. I see. So I think what you're suggesting is there are probably assumptions that Ashutosh is making, and it may be good to capture those assumptions or background information. For instance, this one, hey, temporarily privileged true because we want it, but long term, we don't want it privileged to temporarily use a root. Long term, we definitely don't want user root, that kind of thing. Okay, I'll remember this and keep it to the bucket list of our next meeting with Bruno. So we figure something out about this. Great. Thanks, Ashutosh. Thank you very much. Thanks for this. So the idea is some form of running notes or lab notes or don't forget this. Or I did this because to remember current decisions, right? Right. I guess it didn't work. Right, exactly. Yeah. The other cool thing about that is sometimes those running notes are a great source for an eventual blog post about, here's this technique we didn't deploy all the way to production, but it works in some cases very nicely for this. Great. Thank you. Anything else? Okay. Thanks, everybody. Recording will be available probably within 24 hours.