 Welcome. This is Jenkins documentation office hours. It's the 23rd of June 2023 Asia time topics on my list Google summer of code open pull requests of interest and a possible discussion and review of Java 11 to Java 17 changes in the documentation. That one I call a possible because I'm a little weary tonight so we're going to limit ourselves to probably not more than 20. 20 minutes. Any other topics you'd like to be sure we put on the agenda. Looks good to me. Alright, so I should tell us about how things are going on the Docker Docker quick start. So things are going a little slow this week but we have created a working example with jobs to it already has one job you can let me share a link. Great. Okay, so are you okay if we look at the link together or at the at the example. Yes, yes. This one I shared with him. Great. Okay, so let's. Here's what. All right. Experiment Docker. Okay. Second example. And so if I clone your repository. Are you okay if I just build it myself locally. Yes. Great. All right, let's do it. There's a key gen script before. Right there, you can run it to generate your own keys so that for connecting and agent Jenkins agent with controller. It generates new SSH keys every time to be secure. Okay, just a moment let's. Okay, whoops, I would help if I give the correct clone command. There we go. All right, so here is my. You suck repository. And you say experimental Docker compose files and then oh too. This one, this branch doesn't have the SSH keys. Okay. Is in different branch. All right, so which branch is there a particular branch you recommend I be on one of the pull request branches or. Yes, this one first one new feature. Okay, so how about 42 feature. Yes. All right, good. Okay, so here we are. First render a script then. Compose up with deep. Okay, and so it creates. Oh good okay it does it locally so it's not not putting them into my into my set of keys. Okay, good. And then. Docker compose up. And I think that's is that enough right there just Docker compose up. You can add the option to the terminal later. Sorry, the minus the option for what. At three of the terminal after the containers are running. I'm sorry, I'm not. So Docker compose up minus. You're using the previous Docker compose here to add slash is between Docker and compose that. Okay, Docker dash compose. Yes. Like that. Yes. Okay. All right, so it's building. Downloading plugins. It uses a custom Docker file right now to build the image. Good. Oh, that's an interesting choice of upgrade state. That's fun. Yeah, that's we do plan to move afterwards. It's because of faster to make things faster go faster right now. Okay. So I've currently got something listening on port 8080. Let me do a quick check to see if I can interrupt it. I was trying to duplicate a bug. Just a moment. You got you got an error because you're. Yeah. And that's no shock. I knew I had, I knew I had a colliding service on it. So that's not a problem. I just wanted to see if my, my tests. Okay. My tests have passed far enough that the bug I was trying to duplicate can't be duplicated. Good. So I will just go interrupt that. Okay. Now let's do that compose up again. Okay. So now if I look at a Docker PS. There is an SSH SSH agent running separately and a Jenkins controller. Okay. And did it export the port 8080? Whoops. Wrong one. Home. Testing dash. It did. Very nice. Okay. Admin admin. Okay. All right. And here I am with an agent. And the agent has a. Nice job is not configured in this branch. It's in separate branch. I think this one was created earlier. And that one was merged. So job is not here right now. But it's added in the main branch. Excellent. Okay. I know I have to, I have to do some of my usual experiments. So let's see what kind of agent we've actually got there. And then updates. Let's update all the plugins to latest releases. And see if the updates persist. Across a restart. Okay. So it's restarting. I'd click the restart and will it keep running. Sure. So you, you configured it with the on. What was it on restart on failure? Yes. Thank you. Okay. So restart on failure is configured. Very good. Okay. So patients. Apparently I need a faster computer. Okay. Good. All right. And plugins are up to date. And Jenkins URL is empty, but I am going to configure it because. I know what it should be. And it got the correct value. Oh, very good. Oh my, very impressive. Okay. So now how did it, that's, that's, it's inside a container. And yet it got the correct address. Very nice. That's actually in my best thing. It was not getting better. I don't know how hard it is. Okay. Well, now I am running somewhere other than local host. Right. So I connected my web browser. To a fully qualified domain name. Maybe you connect your web browser to local host. Yes. Yes. That's okay. And that would do it then because. What Jenkins does is it uses the address in the web browser. Somehow to, to populate that field. Nice. Okay. Well, we do plan to use that update wizard. When we. Upload it and mainly so it will. John Mark mentioned that it will solve that problem. Very good. I do have an open issue right now regarding that warning that you are. Okay. And, and, okay. And I see it. Here's the indicator. All right. So this agent that you've got configured, there is running Debian Debian, the Debian Debian operating system inside the, or the Debian utilities inside that. Inside that agent. And if I look at the, the root content at the root machine. Let's see, how do I change it? Let's give it. Oh, it's got the same labels. Good. It's also running Debian as expected. Very nice. Okay. Good. They didn't have a job. You can run a job example job to test it. Right. So if I create. Hello. As a pipeline job and I go click. And say, let's do this. Hello world. Boom. Build now. And if you got declarative pipeline installed, that should work. You did very good. Nicely done Ashutosh. Very nicely done. Impressive. Thank you. Nice. Okay. So now what changed here? Oh, the SSH key changed. Okay. That makes sense. So what and your record? Oh, good. And you chose the right SSH key form. Well done. Thank you very, very much. Yes, we did have an error with RSA. It was not working that. So we shifted to. Well, and, and I prefer ED 25519 because there are at least some voices in the security community who say it's slightly more secure. And I like it because it's much less text. That is my kind of public key, tiny little thing. And so after this, we are working on the tutorials that uses Docker, the previous Docker commands. There are four, I think we have open issues regarding them and that and right now the mid mid evaluation is coming. So on 6 July. So this week, I think I'll be working towards that. Very good. Congratulations. So the ones that that that gives me hope that as you're making progress towards the ones that I was dreaming of were these right, the build a Java app. And so you're aware of these, this, this terrible, awful, awful thing here. Yes. These three and there is one with pipeline one also. Ah, okay. So there's, there's an additional one that I'd missed. That's. It's, is it this one? No, not Jenkins file under. It's on pipeline section. Oh, okay. All right. So it's probably this one end to end. Good. All right. That, that is marvelous. Okay. So, so just as a check, all right. And you very nice. You didn't include blue ocean in this particular image. Cool. But, but we also don't have the pipeline graph graph. Is that right? We don't have this one. This one doesn't have the tutorials one. We are working on tutorials one that. And which will include the pipeline graph. Okay. Instead of please. Oh, good. So you're going to go for pipeline graph. You instead of blue ocean in the tutorial. Yes, that's what. But we haven't decided it fully, but I was thinking. I certainly, I certainly like that. I think this is a good excuse to consider a break. To consider a break from the past, right? Because why not use the new thing. Instead of carrying along all the baggage of the old thing. So graph you pipeline graph you is. There we go. This one. That's exceptional. Anything else you'd like to show us. There was one example of job, but we already did a run job. So, okay. That's right. Now, and tell me about the storage. How does just from my own education. Does this use volumes? Yes. Right now. And so it doesn't use named volumes or unnamed volumes. Right now it does use name. Okay. So this is probably the name volume. There's zero two. Okay. So will that volume then persist. Even after I even after I stop the, the Docker container. Yes. If you, if you do want to delete the volume to you'll have to use Docker compose down slash less volume. Okay. So if I do, for example, if I do a Docker compose down now. It will preserve it. The volume will survive. If I do a Docker compose down and it's shut down. Let's see. I bet that is. Okay. These are the containers. Containers network and. Ah, okay. So it really when I did Docker compose down, it actually removed the network as well. But the volume is still there. Okay. And then when I do a Docker compose up. I'll remind myself Docker dash compose. And now if we wait patiently for this to start. And the job will still be there. It won't have been lost. So my, there it is. Okay. Now the, the complication then for a tutorial user is they may end or, or do you envision using a different volume for each tutorial? No, we, we did have a discussion about it. We should use this volume, the name volume or not. Since it uses, but we didn't decide. We, we didn't completely decide what we'll use in the end, but right now we are using. And that, that sounds great to me. I was just curious. If I'm not sure how users, if users tend to do one tutorial and then stop, or if they do two, two or more tutorials, and I was worried if they, if we have a single volume, is there a risk that the two tutorials might collide with each other by using the same volume? Yeah. So that's, that's very elegant. Nicely done. Congratulations. Congratulations. Anything else you'd like to let me put the link to your, to your repository here so that we've got it. We created a job, ran the job, watched it run on the agent. We installed the plugin, right? I confirmed it worked. Saw that the agent and the controller were Debian. Very nice. And so then you said that the next step, next target is the next sort of big target is using Docker inside somehow. Yes. And the like tutorials need Docker and Docker to work. So we'd have to do that. Yeah. So, and I, I am not, I am not clear how that, how you'll do that. But we know we have a working example. Well, sort of. We have a working example in the current tutorial, but it does not use an agent. Yes. We were thinking of creating Docker and Docker, but example, what we decided it will be, it is a security risk. So we'll put that towards the end, but for tutorial, we will need it. Exactly. See, that was, that was one of the things that I look forward to you exploring to see what alternatives are there for easy execution of Docker operations in an environment that's already running in Docker. And that's, that's the place where I, well, this horror right here, I'm delighted it works, but it is scary what it's doing, right? I mean, it's, it's doing, it's doing things that this Docker and Docker stuff is doing things that are, have security risks. Good. Very good. Anything else you want to, want to share with us? So next, this week and next week, I'll probably working to on the midterm presentation too. All right. Meg, I've got a question for you and for me then. So let's go to, I want to look at the Jenkins at the installation instructions for Docker. So installing Jenkins on Docker, if I remember correctly, it does a full Docker in Docker even here. Yes. Okay. Ashutosh, you'd already seen it. It does. Yeah. So, so we need the same, the same technique here as we need in the tutorials, because it's, this is also doing Docker in Docker. And it was doing it specifically because we wanted people to be able to use the same pattern to do this as they did tutorials. Good. Okay. Great. Nice. Nice. Needed for, needed by four tutorials. And the Docker install instructions. Good. Very, very good. Anything else, Ashutosh? No, nothing else. Okay. How about we take the next topic then. I'd made myself a promise that I'd get done by in about 20 minutes. We're a little over. Meg, if you're okay, I'd like to take the, just this one topic on the open pull requests of interest we've got. You remember Jeffrey Chen had submitted a pull request that you would evaluate, you had reviewed. Right. And mold wiki stuff, right? Exactly. It was a migration of two things, the administrator, some administrating material and the best practices page. And so I started working on it last weekend. And while working on it. Found that, Hey, I couldn't make changes to it. So I ultimately ended up taking Jeffrey's work. But I closed the pull request. So kept all of his commits, but closed the pull request and then split it into two pull requests. So because the original thing was targeting both administering Jenkins and best practices. The split into two was one half for administering Jenkins. And one half for best practices and the, the administering Jenkins piece. I felt like was well enough reviewed after your reviews and Kevin's reviews that earlier today during docs office hours, Europe, I merged it. All right. And so what we'll see is that Jeffrey's work here. And the things that I had added to it ultimately did end up in the book right here. Let's go look at it. So I think it's in, is it managing Jenkins configuring the system? Here's the Jenkins. Like, oh nice. Oh, and it's no longer a work in progress. Right. Yes. So, so a win there. Now the next step needs more text and that's this. This best practices thing because what I feel like is. Recommending best practices is a dangerous statement of opinion. Right. And we want to have good opinions before we go all the way. Right. So I took the text that was there and then I added a bunch of my own opinions. And of course that's dangerous. But that's what I want. And I had some places where I said, we need more words and Kevin said, we don't take that out. That's junk. And my answer was no, we really need more words there. Right. I have nothing against best practices. If you get a disagreement, then you can say some people recommend doing this because of this. Right. Other people it's very Talmudic, but, but it works. Well, but using a Talmudic approach, I think is the right approach. It's, hey, let's talk about the compromises because the word best in this case miss might be misperceived as the one true way. And that's not what it's describing. Right. It's describing for a particular set of circumstances. Here are a set of good practices that have worked for some people. And we've gotten the convention of calling a best practices and it's awful. And, you know, but it should be good practices. You're absolutely right. Yeah. Yeah, exactly. And a software testing community that I'm in. Loves to, to, to berate the use of the word best in that case, because it's a, it's what a superlative. It's, it's a maximal thing. And the usual answer is nonsense. They're not maximal. Right. But the cool thing about this one is that Darren has four or five videos that are now embedded in this. And so let's go look at it briefly to see how it looks in the, in the prototype because I think it's the right approach. Now, one of the problems with this approach is it's. Well, it's imperfect like anything. But here, if we look at using Jenkins best practices, what you'll see is a series of videos that are almost back to back with each other, GitHub organization folder, get lab group, uh-huh. Bit bucket team or project or giddy organization folder. Now I could separate each of them with a heading or with some text, but they are most, most of our users will have exactly one of these and no more. Right. And so having them choose now, maybe it would be better if there were subheadings here so that in the table of contents under organization folders, they could click. GitHub. Giddy. Bit bucket because that might get them closer navigation. Right. The other thing that I haven't seen these videos, but is there like do these, do you have two or three points that are like your summary takeaways? Cause the problem, one of the things that bugs me with the embedded videos is it's a 20 minute video and I watched it and I liked it. And there were a couple of things and it's like, what exactly did they say? And this is not fast forward as nicely as my Tivo does. Right. I've been here trying to jump around. It's like, where was that gem? If there are a couple of gems that could be out there or the other thing is summary commands that I could copy and paste. It's very hard to copy and paste out of a video. Good, good suggestion. And that would give us an excuse then to put headings and to put a brief two or three or four bullet summary of, of that video segment. And then same for this video segment and same for this video segment. Good idea. I like that. It's the stuff that I, after I've watched the video three times and consumed at the stuff, I want to go back to quickly and grab. Right, right. So what you're saying is there, it is far better to illustrate the hot spots with text, copyable text. Good. I like that. Okay. Yeah. Good suggestion. Now the others. Yeah. See, these were, these were, okay. Now we're really getting in Markweight opinion mode. And this is, this is, this is a dangerous world, right? But it's a good world. I do go up all pine all you want. Right. So what I started with was, hey, first choice you should use organization folders. They are the most efficient way to do it. It means you, you, you create one job and it will create multi-branch folders for every repository and jobs for every branch and massive automation. But there may be cases where multi-brand, where organization folders aren't quite what you need. Okay. You could then step down one level and do multi-branch pipelines. And it's, hey, if something prevents you from using organization folders, then at least use multi-branch pipelines. And this is where the needs more wisdom. Why is multi-branch pipelines not a link to the chapter, the page about multi-branch pipelines. Organization folders was. I'm not sure I understand the question. Percent. Wait a minute. Go, go back where you were. See organizational folders that in the line just had it. It ends, but help me. Oh, wait. Okay. Just above this one refer to the organization folders documentation for more details. Right. Now go down. Okay. So now you want me to go down here. To see this one where it says. There it says, if something prevents you from using organization folders, then use multi-branch pipelines. So I'm saying they are multi-branch pipelines should link to. Oh, oh, I see what you're saying. Okay. Good. All right. That's a, that's a good, good suggestion. I should probably follow the same pattern. Let's see. Well, let me think about that. Okay. Because the, what I did was since this sent the closing sentence had the hyperlink in it here. I put the closing sentence with the hyperlink here as well. But what you're saying is. I see. Okay. Now, but, but it may be that this wording is so weak right now. That's why you're even seeing this word at the end of this. That's right. I was at the end. I would say keep it in the back of your mind till you get the more words in and see what you've got. Right. Good. And also I would have, will those sections link back to this. They, they would generally not because best practices for me are a high level summary. And the documentation is a detail and there's not much gain for the user to jump back to the best practices stuff. Yeah. I don't know. I, I like lots of links. And some people complain about getting stuck in a circle. And I don't, because you never know where people are going to start. Right. And, and now, now this is one where, where it's, it might be worthwhile to consider. So this page, for instance, this is actually a page that Kevin Martin's detected was not in the, in the list on the left. It was not in the index on the left. Oh, so he moved it. He put it there correctly. Very nice. But it, it's rather older descriptions of some things. So for instance, it mentions GitHub organization or a BitBucket team, when in fact right now we have five or six organization folder implementations. GitHub, BitBucket, Giddy, GitLab, Tuleep, and I think maybe even one other. So, so we've got multiple implementations of these. And I think they're actually mentioned all the way at the bottom. Nope, nope. They aren't. There is a page that mentions which ones are full organization folder implementations. So, so this page may, may benefit some from at least some minor rewrite. Right. Okay. So that was the, that was the one I wanted to show. And I think I've, I think I've extracted the topics I needed from, from which is there are things to improve on the best practices page. And maybe one is a disclaimer describing that the words, the word best doesn't actually mean best. It means in some context for some people, these have been good practices that have worked for them reasonably well. Okay. So. All right. Well, any other topics I'd propose, given my level of weariness and Ashutosh, let you get some sleep as well. Oh no, it's start of your day. Get, let you have a good day today that we call today for done unless there's something else you wanted to go over, Meg. Nope. Sounds good to me. Ashutosh, anything else for you? No, sounds good to me. All right. Thanks to all of you. Good meeting. Good work by everybody. I'm impressed. Well done Ashutosh. Thanks very, very much. Thanks.