 Okay, this is being recorded. This is the Jenkins documentation office hours. It's the 17th of August. Thanks for being here So I've got Agenda topics that have been placed. I think They were they came mostly from you Jonathan So let's take a look at them and we can add additional topics as needed sharing my screen now okay, so Google season of docs announcement issue monitoring so update missing redirects and The v-hosts that didn't change. Those are two good topics is for sure Any other topics that people would like to put on the agenda I was just doing some work on the wiki migration sheet and So we can look at the slow but steady progress there Any other topics you'd like to put on the list? Well, I wanted to Discuss if it is appropriate for this meeting Mark something related to Configuration as code because I was working last week and I don't quite understand the purpose of tools for example section inside configuration And specifically when I was putting Special tools, I thought they will be appeared in that docker image, but they didn't so just Understood the purpose of Tools section. That's a very good one. Okay, so I'm gonna list tool configuration choices as as the alternatives and there are choices like Jenkins tool installers Docker image Includes the tool Just helm chart count. Oh Helm charts another good one. Yeah, helm chart Includes the tool Static agent includes the tool Good, those are those are all excellent Those that's an excellent topic. What are any other? Do we count CLI? Do we count scripts and or? I would I would not put scripts in and oh, oh, I see. Well That's a grip that's going to install it Recommending this but Alright, so I'm also going to put Meg's crazy ideas for crazy crazy groovy system groovy ideas That's great, and I like those those are brilliant That's those are a lot of fun because as sure as it makes suggests it We know that there is someone in the world who has done it and done it and loves it. So absolutely good System groovy scripting is not that person make just knows people who tend to do things like that exactly that's brilliant Okay, and part, you know, and there's some questions to how much we want to encourage those people or do we want to just You know, don't ask don't tell we know they're there, but let's not encourage anybody else to join their lives, right? Good. Okay Any other topics Um, if the tool was a plug-in then cask is an option, right? Or is that Jenkins tool? Well, so plug-in plug-in is a different thing. So let's put that I'm going to put that separately as at least in this context Comparing a plug-in and a tool in Jenkins vocabulary Okay. Yeah, because there's a there's a distinction there and the distinction is it may actually be Quite important to understanding why there are so many ways to do tool installation, right? Okay, good. There are topics Okay, well, so then let's get started and so we've got Google season of docs Zinab has been Abu Bakar Has been accepted as the Google season of docs writer for Jenkins The community bridge projects Whoops bridge and other projects are still Under consideration and so we're not we're not giving up on those right now They would they have the same challenges they did before and eat funding etc need mentors But looking forward to this And this one is Jenkins And the focus will be on Kubernetes Jenkins on Kubernetes And just to clarify this is not related to Jenkins X project It is not that's a good point. So Not related to Jenkins X because Jenkins X is a different Very different approach to how we how you do Kubernetes. It's really absolutely cloud native whereas Jenkins looks an awful lot like a large application. You deploy the Kubernetes and it's a different a very different paradigm Very different way of working. Yeah, there is a Google season of docs project for Jenkins X as well And it has a writer assigned to it also, but that's a it's a different project Mark, are you saying that the Zyna proposal accepted was about to the Jenkins on Kubernetes? Yes, even though even though Google season of docs says the wrong project description. Oh, yeah, are you a warning about this? Yes, there is another topic there, right? G-Sug made them and they made a mistake in describing the wrong project. Okay. Okay, and and we've already clarified that We've asked them to make the correction. We've confirmed with Zyna that she understands that the project She's working on as Kubernetes related not plug-in related. Yeah, good. Good catch and extra points for being attentive That's very very good. Yeah, it's important to read Sunday night when I read it, I was completely dismayed. That's great I'm glad that you but that's the wrong project. We absolutely that is not the project We chose as as as the mentoring team, etc. So, yeah Nice Yeah. Alright, anything else on Google season of docs before we go on to the next topic. Okay, issues monitoring Jonathan. Thank you again for your attentiveness to those. So missing redirects. So let's take a look at this. Okay, so this one is a V host change For Oh, right. Right. This is and this one inspires. Okay, so Jonathan, I'm going to go ahead. I'm not sure if you can see my screen. I'm going to go ahead and apply my proposed change. The redirect. Okay, no problem. How to view in your language and it was pointing to just the using book, whereas we've got a page in the using book now on using it in your local language. Oh, some may mis-type, I guess. Could have been. Yes, I Yeah. We should directory them to the page. Okay. What was your question, Meg? Oh, I'm just editing your comment. Normie Directory is a verb is intriguing. No, no, in this case. Okay, now I have to show you that the current message redirect, which is a very specific term in the HTTP protocol. Yes. Okay. But directories not a verb. No, correct. Right. Yes. Okay, so I and this one. This one I'm also going to go ahead and commit it because this Jenkins behind proxy page. I had initially incorrectly classified it as part of a reverse proxying thing and it's not this is a proxy not a reverse proxy. And you don't want to get me started on how crazy that makes me to think that we have to do two concepts that use the word proxy that are radically different from each other. So this one I'm just going to remove the remove redirect for page not yet converted. Okay, so behind proxy and reverse proxies as different style to use. Right. Yeah, so, so in this context, a proxy is is a hint of. Okay, this is now I'm going to stand in the middle. I know. Well, it's in the middle. Yeah, like a ball or something. Well, or, or a 1520 years ago corporations were very frightened of giving. Their, their employees access to the internet. And therefore they would install proxies that everyone has a channel all their traffic through. That's what Jenkins behind a proxy is talking about. Whereas reverse proxying is something that's very close to the application is connected to the application and handles traffic for exactly that application. So, okay. All right, so now now the perplexity here that I, I think this is ready to approve. But the challenge I've had is that the previous preceding changes I think you noted it here Jonathan was that we've got changes that are somehow not having the effect that we expected. Exactly. Exactly. I, it's the, the previous lines. If you go to the horses. I don't put the numbers. Yeah, so, so this is, this is the perfect example of it. This URL is absolutely being redirected. And yet, if I open that page. Exactly. And I don't know how I can't explain why either. I am completely perplexed by it, because it everything I know about how it's supposed to work seems like it should. And yet here we'll even prove it one more time. So this is one that I may have to discuss with Olivier Bernin, or with somebody else who understands Apache redirects, because this should redirect automatically and in fact it does not it stops on the wiki page. Okay. And I wrote right on the PR, I put these links as duplicate ones. So I observe it to the already exists. So I put the on our agenda to discuss because this Excellent. Thank you. Yeah, and I wish I could tell you why it's doing it but I just don't understand it, but it is clearly it's flawed it's wrong. And I just don't get it. I don't understand. And yet this this link the 3204 that is the issue that we originally used to track the reverse proxy configuration page improvements and it's closed because the page has the new content. And I think it's exactly the right kind of thing that we did. However, the redirects are still incorrect. They just they aren't, they aren't improving our They aren't helping our users get to the better pages. Okay, so with these updates. I already update our week migration control. So maybe we have another graphic images and the second tab week tab. Okay, so let's take on the bottom on the bottom the statistics. Well, out the graph is now it's up here. Nice. Okay. Okay. Is this this data is computed live from the from the yeah contents of the sheet from the first tab. Yeah. So if you update the stats there, the graph this updates here. So we can. It's following the our progress. Now we have a lot of done a lot of thought available to work on the blue one. So, and available in this case means there is an issue recorded in GitHub. Yeah, there are various issues. So the issues are available to contributors, the yellow one it's waiting for issues. Yeah, so for me that means available someone has has created an entry as a GitHub issue and that issue is probably good enough that a new contributor could actually start work on it so when October first when we when we enter October and October fast. This set of right now 17 would be a good, a good starting point. Exactly. I'm planning to visit the another waiting issues planning the place to to migrate the pages of places need to be split it in several ones. So we can stay prepared for the next October faster or new contributors. What did you get. Think about. I like that a lot that is that sound wonderful. We know that beginning October first and continuing through October 31. So there's a major initiative promoted by Digital Ocean called October fast and last year we had over 50 contributors no no I take it back I think it was over 100 contributors during that month. So we need to arrive at the start of that month with probably 20 or 30 or 40 ready to go. Instead of the current 17 so the your your progress and helping us triage review and create. Yeah, well described issues is very, very valuable. Okay, so I will start to work on the stock and the next days. Excellent. Thank you. Nice. Now on the suspended and these are, I believe these are ones where their work has been started but they're waiting for a change so these are usually actions for me or for Oleg right. Yeah, it's suspended it's like a plugins that was the breakout or pages that is not more important to documentation. Oh, okay, sorry suspended. Got it. So suspended is something where we're not going to do anything with it. It's anymore. No, right. It's it's a it's a it's a it's another form of done it's a done with us doing nothing. Okay, yes. Right, right. So no more work to be done. Great. No more work. There is a issue. It's not closed. You can see the line six. Yeah. Yes, it's ever and okay the redirecting is working but the issue it's it is open. Oh, okay. So I should be able to see that if I go here and filter to status column. Yeah. Clear all and then done. Not closed. Okay, so monitoring. Oh, see an eye. Oh, good. This is when we could discuss with Vlad so that's excellent. Let's look at this. So, Vlad, we're going to we're going to put you up for a question here. Okay, so this is convert the monitoring wiki page to Jenkins.io. We started but not finished. This one is all right so this one hasn't attached pull request, but the pull request I assume has not yet been merged. Oh no, okay we did merge to us. Nice. Okay. Okay so well so wait a sec let me look let's look at the content. Why did we not close this then because. Okay it's the page is still under development but there's a. Okay, this provides links to various monitoring gap, but I think that's all that the original page. All the original monitoring page did. If I remember correctly let's look at it and see. Okay everyone close your eyes and shame as Mark hacks the URL to get past the redirect. Okay. That's interesting. There's something completely different than I can just provide slide comment on this I was working on one page which is part of our current documentation and created initial release of that page, but it is not related, I guess to this page because it is. I have a little bit of data. Well, it's not even just outdated this is a, they are both monitoring concepts, but my initial interpretation of the phrase monitoring Jenkins before seeing the program was a tool like data dog or like. We've got the, the examples here on the page that you, you provided for us a data dog or Prometheus and Grafana or Java melody those are tools that that watch the health of the Jenkins server itself of the Jenkins controller. And those are things that an administrator uses to say, is my Jenkins running well right now. Whereas this page monitoring Jenkins is talking about tools that developers place on their desktop to pop up a notification that their job had a problem. And they're they're completely different facets of the notion of learning something from your Jenkins server. I understand why this one is not is not closed then because. Yeah, so that one, I would, I would shift it to to be done. But see what's what's the correct status for that Jonathan can you help me. It's. It's a you will close the issue or not. No, because because the issue progress. Well, so in this case it's not even, it's, it should just be available because it's, I don't think anyone started the writing on it to say, Oh, this is how you use these build notification tools. Okay, so maybe it's interesting, but there's some notes on the comments. Because the issue is it's. Oops, there has a PR course. Ah, okay. And so that may indicate the comment on the the github not in the week. Right. And so this one is, let's do that and go to the github issue. Okay, so here we want to break the link and I'm not sure can I am I allowed to break the link. Yes. Okay, good. Break the link to the PR. So there isn't a PR matching it. And I'm going to put a comment here in the text. This is this is a really terrible awful example of how not to do how not to describe one of these issues so. And please don't take this as the right of the example it's, this should have been much better described than it was the monitoring. Vlad, we will keep it working on it or not, because it's a good point yeah so Vlad I assume we you would not continue working on this you'll you've picked other things you're working on you okay if I take it away from you. Yeah, it's okay. Okay, very good. I think it's available. Right. The monitoring page concept in this page is related to developers being notified of a change of status in one of their jobs. So why isn't that renamed something like monitoring Jenkins job status. Good idea monitoring Jenkins. Yeah, I agree. Yeah, it should be so. So, for example, if a test fails in a job, but from a recent change, the developer needs to investigate why. So what we should really say is use the document conversion instructions convert monitoring from from the wiki to a Jenkins.io a new Jenkins.io page. Notifying developers of job of changes. Maybe we just call it notifying developers. Notifying users even better that's good. Yes, very good because it's not the only developers. Right. Yes, notifying users of the new page. Describe should describe the various tools available. Provide desktop notification of status changes. Let's see things like pass or succeed success. Failure success to unstable, unstable to success, etc. Should we specify status changes for the job. We didn't. Oh yes job status changes very good. Yes. I don't need that. So, this is not about monitoring the health of the Jenkins controller reuse. Let's see agent failures, etc. a better description now everybody okay with that is the better description and correctly not assigned. Okay. All right, excellent. Good. Okay. So it's it's been updated to show that it is now available. And it's zero. It's okay. Oh, cool. Updates to zero. It's automatic. Excellent. So the it recomputed all by itself that's great. Okay. Yeah. Okay. It's not a tab. It's a issue maker generator. To the next one. Just put out. Okay. Anything else that we need to do with regard to wiki conversion progress Jonathan any topics you wanted to be sure we covered here that we haven't yet touched. No it's completed. Thank you. All right. question and discussion. Would you like me to start on this? Yes, please. Or you could start, or I could go on blathering about the difference between a plugin and a tool. But tell us what your experience has been so far. Help us understand. And that way we make sure we get a good conversation started. Yeah, thank you very much. And I would be glad in case if you correct me if I'm wrong. I have much longer and better experience on this. So in general, my understanding by watching all these videos on YouTube and watching different recordings, that configuration of code, S code, is the modern way and current way of configuring the Jenkins instance, which we are trying to configure. And this is the way to go, basically. So inside configuration as code, which is plugin, basically, and it is for, again, the sources on GitHub, there is inside, I believe it is Jenkins YAML file. It is called, there are different sections. And one of the sections called tools. And maybe I misunderstood the purpose of this section. But my understanding that at least was my understanding that whatever we put inside the tool section, these two will be installed automatically inside. For example, I was playing with Docker image inside the Docker image of the Jenkins and we'll find out that too. So I was exploring two alternatives, basically. One is installing this tool by modifying Dockerfile and creating your own personal Dockerfile and kind of manually, in quotes, installing this specific tool, for instance, JDK, specific version of Maven as the tool and so on. And I thought that in case, for instance, just in case, if we'll put certain tools inside that section, it will be also installed. But maybe I misunderstood the purpose of this. I'm not 100% sure. But I believe that the tools in configuration as code is installing for where you can put tools on the Jenkins controller itself, which I believe is not the recommended way to go. But on the system configuration page, I believe there's a place where you can configure tools. You're certainly close, Meg. So there's some subtle, subtle things happening there. So Vlad, you've got a really, really interesting combination of things that you're considering. So on the one hand, Docker images and the promise and the benefit of a Docker image is it can provide us a stable and static set of initial files in the file system that we're going to use for that image. So the common pattern is, I want to build a piece of Java code. I need to build it with Maven. I will reference the Docker image that the Maven project provides called Maven colon 3.6.3. And that will assure me that the image I'm running starts with Maven already installed. And so in that case, the Docker file is doing what you were describing initially as it's already got the tool inside the Docker file. However, there are people. Oh, go ahead. Oh, I was just trying to add what exactly mentioned one approach is to base this image Docker image on Maven, which ensures that Maven as the tool exists over there. Or base from, for instance, LTS image of Jenkins and manually install Maven inside Docker file as the tool and provide our own Docker image. Right. And now there, that's a good place to clarify. If I've got a Jenkins controller, got to quit staying master, a Jenkins controller, and the Jenkins controller, we generally prefer to not run builds on the controller. We want builds to run on the agents. So installing Maven on the controller actually won't help. So because we don't want to run builds on the controller, we want builds to be run on agents. And so we don't install Maven on the Jenkins controller because we want to keep builds off the controller. The build should run on agents that are separate from the controller. And I say Maven as an example, because it may be any tool. And also I was planning, and maybe I have wrong approach, please correct me, as very simple example of running Jenkins, doing agent list instance, if it is possible. So running just controller and enabling Docker inside that controller. So we can use pipeline for instance, declare the pipeline and installing through plugins.txt file, blue ocean or whatever plugins we need. And inside pipeline, we can specify whatever tools they will need by doing agent. So another Docker agent will be. And inside that pipeline, we can specify whatever tools we need. But so this is like approach I was trying to follow when creating something like for future tutorial for like showing how to deal with, not production, of course, how to deal with pipelines and to show it as possible. Well, Vlad, just to share how you use Jenkins Docker and GitHub here all together. In our company, we keep Jenkins working and orchestrate all jobs. So for example, our systems, the job when we commit something in GitHub, Jenkins just to get the push notifications. So we start to build in the Docker image and we're using ephemeral containers in a build server, not inside the master node. So the check out the project there, build the Fed container, put the application side, commit the Fed container in our another repositories about the versions. And then we publish. And the final job work, it's clean up the build server. So because we are using ephemeral containers, there is no garbage to work on. It's just temporary. So just Jenkins on the master and agents use dockers just to build the applications and it's close everything at the end. And we keep the Jenkins file configuration at the GitHub too and the docker's file, there's another repository too. So it's everything working together. Right. So we have classical kind of controller agent configuration where executing all execution are done by the agents but controller manages everything. And I think that actually you were also angling, you were also moving towards that same kind of thing as you were talking about Docker in Docker because even if you configure a controller, if you allow it to run Docker inside that controller when it launches a new Docker image, it will treat that as an agent. And so you were actually doing agent-based development as well. It's just well hidden from you. So you ask the controller start a job. The controller starts a job and the first instruction in the Jenkins file says Docker file this. And what Jenkins does is creates an agent using that Docker file and connects that agent to your controller. And so now it's all on the file system of the computer that's hosting your controller. So in terms of execution capacity, you actually didn't get any extra execution capacity but the file system is completely isolated by the Docker container. And it's, as Jonathan said, it's ephemeral. It lives only long enough to do the work and then goes away. So the technique you're envisioning is actually a good example of the technique of using don't build on the master, build on agents. So- Exactly. So first and foremost, I say ephemeral container it's because it's a small container you just have the maven style it. So I call them container maverick is a good thing I need to do and throw away. Right. It's the same for Ruby on Composer or any kind of too. Well, thank you for pointing this out. And the reason why I explored this solution because I thought, well, it's another reason to amplify that. Well, Jenkins is smart enough to do this job communicating between controller and agent by itself. You as the user don't need to establish and think about how this controller and agent will communicate, which ports they will be used and so on. Well, socket communication. The way how you run this Docker image important, but not much of work. So Jenkins does a lot of work because it is like very good software. But here I well wanted to mention that I was trying to explore configuration as code plugin which is kind of separate from Docker or like different plugin and different thing. And when I was trying to put some tools into section, it was not appearing to inside Docker container. No, no. Is it because it is controller or is it because of I'm doing something wrong? It's because that's not, yeah. Well, so it's, there are some subtleties there that it's probably important to understand the subtleties so that you know when you would use which. So a Docker image is generally assumed that it will contain all the tooling already. A Jenkins tool is a concept from well before the days of Docker. Docker wasn't even a glimmer in some peoples in the architect's eyes when the concept of a Jenkins tool was created and what a Jenkins tool is, is a chunk of Java code that knows how to install a tool onto an agent if requested to do so. And it's the if requested to do so, the way we make a request to install a tool is we either refer to a label that says, oh, I wanted an agent that's labeled with this or in pipeline we might use a with tool name like with ant or with Maven wrapping block. And then Jenkins will look, do we have Maven? Oh, we don't, I'll go grab the installer that matches the label that you just gave to make sure you have that installed. So I use tools and labels all the time with my relatively static agents because it lets me say, I need Maven 3.6.3. Here's a tool for it. And the installer is located on this HTTP server. If you don't already have it, copy it from there and install it. And Jenkins will do that for me. So the distinction is Docker images don't need that. They could use it conceptually but ultimately you would have to, inside the build steps with Docker, you would have to make a request for with ant or with Maven and then it would go do the, oh, now install a new copy of Maven. Right, Mark, this part I understand how to do this but I was referring to Jenkins as code, the tool section. So the tool section, I should address different like people who developed this plugin. What is the purpose of tool section inside Jenkins as code? So it's used to define those tools. Maybe I can show, would it be okay if I show you a demonstration of a configuration as code file that has tools in it? Yeah. So let's go ahead with that because I, yeah, so let's look at, and this is a public repository so I can embed the link to it. Let's see, so let's look here. And if we look at the LTS with plugins. Okay, so here is a Jenkins.yaml file. Okay, and is that text readable? Do we need to go a little bit larger? There, maybe that's better. Yeah, that's good enough. Yeah, and it was tools. Get to where it is. Oh, here we go, tool. Okay, so what this Jenkins configuration as code definition file shows is it's going to define a tool named ant with one of the tools, one of the ant tools will be labeled ant-latest. And if someone asks for ant-latest, it will into a subdirectory named Apache ant1.10.8, unzip the thing it downloads from home.marquait.net, such and such, and install it. So, but I think that's, that fits the concept that you've already got of what is a tool installer, right? I see because I was like doing this without, without in properties I guess that there was a name and home, I think, something that is specified budget. But thanks for pointing this out. Well, so Meg, go ahead. You had a question. This is what, this is for the tools configuration that appears in the UI. I think the system configuration page, right? I've never seen in the documentation any place where it explains well what that tool definition is. Agreed. And I think CASC, you can see in CASC what they put together was they sat there and looked at the system configuration file and tried to pick up everything that was there. So, and the other slight one is that apparently the only documentation for CASC is the read me to the GitHub repo. Well, there's lots of documentation on configuration as code, but yes, it is still not nearly enough for what all the people would like about it. So this is the page that Meg was referencing, the system configuration page. And when I click the ant installations button here, you'll see the ant dash latest with an install automatically checkbox. And here is the downloader that, or the file that will be downloaded and the sub directory that will be created when it's downloaded. So I guess if I understand correctly, whatever we put over there, it will dynamically create portions of UI which user can use while configuring the Jenkins instance. Right, right, yes. So this and the configuration as code, if we look at configuration as code, it will even do one step better for us and it will, let's see where it is. Oh, here it is right here. So if we view the configuration, it will show me the definition of all those things that I just showed you. So that thing that I did was, is here in this configuration as code thing that I can just view. And it's ready to copy and paste so that I can copy it right from here and paste it into a text file. Now you mentioned git and I have to apologize, I maintain the git plugin and the git plugin is, has some flaws and some problems in its use of the notion of tools that I have to just apologize for outright. So git specifically is, has some interesting strangeness and I apologize for that. You mentioned it, one is this thing here where it says home and name and that's all it has. And that's legitimate or just a name, but there is no other tool in the system that has that strange and bizarre behavior. So JDK behaves much more normally, Maven behaves much more normally. So Vlad, did that help at all? Yes, yes, it helps, Mark. Now Meg, your point on that there, there isn't really a clear description anywhere in the documentation that I recall of this notion of tools and how tools can be used well and effectively and when they should be avoided. If you've got Docker images or you've got Kubernetes containers, then tools are typically not used at all. If you've got static agents or you've got agents where you can't really put them in Kubernetes, for instance, you've got a bunch of Raspberry Pis or you've got cell phones attached as agents somehow. Tool installers are quite helpful then. Go ahead, Meg. Yeah, no, when I first started looking, I thought, oh, if I wanna use Maven for my pipelines then I need to get this configured on the system configuration page. That just made sense and then it's gonna flow down and wouldn't it be lovely when I, doing Docker, I say, pick up all the tools that are configured for this Jenkins instance. That all makes great logical sense to me but I don't think it has anything to do with how Jenkins works. Right. And I don't know any place that ever explains that. Yeah, good, very good point that the notion of tools, the concept of tools and how they are used well and effectively has evolved from the original Jenkins to today's Dockerize and Kubernetes Containerize, but the documentation doesn't describe that evolution. And I guess it is like a very complex task to describe it correctly. I think so, at least you've listened to me and to Jonathan attempting to describe various facets of it. And we've described three or four or five different pieces of the puzzle now getting that into a clear, comprehensible, well-ordered, well-organized, well-structured thing. Yeah, that's hard work. Yeah, but I guess when I start to work with you, I study the Jenkins documentation and there is a point there. For example, our documentation, it's like a book of a unit of our experience, the users. It's not, for example, let's describe the first screen on Jenkins, describe the first boat or the second boat on the first page, the second page. It's not like a manual, a user manual. It's like more a book. So maybe because this, we miss points like this. They've applied and make this text for us. Because it's not a user manual, in fact. But this, well, well taken this point, Jonathan, but this is related to this specific plugin. And we have like more than that. Yeah, it's because that plugin, it's become a page inside the Jenkins. Once we start it, there's sections for that. So maybe in the future, we need to have another kind of documentations guided by page and features. Yeah, so the concept that, and I don't know if it's the right concept, the concept, I would make it somewhat similar to the notion of we have the concept of solution pages. It's pretty weak right now, but we have the concept of solution pages and configuring your Jenkins server might be an entire solution page with the whole, because there are multiple ways to do it, right? There's, yes, I can configure with the configuration as code plugin that has certain strengths and weaknesses. I can configure with groovy system scripts. I can, or another solution page using GitHub Well with Jenkins, where it's really the combination of six or eight or 10 plugins that gives you a really great solution. And those are sort of solution focused, but right now you're right that the documentation is certainly not yet solution focused. Mark, on the actual UI for tools, what does the tooltip say? Does it even tell you that like, if you're going to use Docker for your agents, just ignore this? Oh, no, no, it doesn't give you anything nearly that kind of guidance. So if I hover- So it can throw a bug at the software to click the tooltip. Yes, yeah, that's an interesting idea. I mean, in a very, without detail, just to warn them, you know, what exactly is this used for? And I think it's primarily used for builds that you do on the Jenkins controller itself, not the agents, which you shouldn't be doing. No, for me, it's almost exclusively used for agents. But it's biased towards static agents, not ephemeral agents. Okay, and non-containerized agents. Right, most ephemeral agents are containerized. So yeah, it's, yeah. But for example, this setting right here, this global tool configuration for Maven configuration is actually a nicely applicable thing for even dockerized environments. So there are things inside this page that help with dockerized environments, but it's certainly not this button for JDK installations, right? That one, if you need to install a JDK, you should just ask for the Docker image that it is that JDK version. Right, and it's up to the user to decide which path to go, but I thought, well, maybe we can make some recommendation at least for new novice user who haven't experienced. Right, and this is back to the same, the condition I'd shared last week from a brand new Jenkins user who was familiar with GitLab CI, who came to us and said, came to the issue tracker and said, hey, I don't understand what you're doing here. And I was looking for this way to do things with Docker and have agents, and the user didn't realize that they were getting agents just by using Docker. And it was, what did that mean? We had a very poor description of what they were experiencing. We gave them detailed steps, do this, do this, but didn't tell them at all what the results were of what they were doing. So it is, yeah, we need better documentation in those tutorials for sure. So just to summarize what we spoke about, is it all fair to say that, well, we can use Jenkins as code and this is a very good tool, but mainly in case who want to configure the agents, not the controller, or is it? Well, configuration as code is actually very, very good at configuring the Jenkins controller. This, the tool configuration here is most commonly used when we have agents that are static, right? That are, they live for a very long time and we don't mind that they become contaminated and we worry about them. So configuration as code is actually primarily focused on controller configuration on the master. Except tools. Right. Yeah, tools. I would guess most Jenkins installations that are using configuration as code are probably also doing what Jonathan's team is doing of using ephemeral agents. And therefore they probably don't use tool configuration because they rely on their ephemeral agents to already have the tools. That would be nice if some play. I mean, that's almost a high level of discussion, a conceptual thing. It's almost a blog. Right, right, yeah. It would be easier. I mean, you could write it up to then have the specific details for everything but it would be harder to get the big picture. Right. Yeah. We need a big picture thing about agents, the same thing too. You know, what are all your different ways of doing agents and what are the pros and cons for each one? Right. At least we have consensus on the term to use moments. Right. We have made progress on getting a consensus term. Although now we've got to do the hard work of making the change in all the documentation locations. Daniel Beck submitted a poll request just for security advisories and it was what several hundred changes just in the security advisories. So yeah, there's a lot to be done to make that change. All right, we have hit our hour, are there, and we have, I think, covered all the topics that were on our agenda, anything else before we close. So maybe we should take these other topics for a future session because helm charts are a different technique and system groovy script is yet another technique. So let's remember those for a future session, Vlad, if that would be okay. Great. All right, thanks everybody. And we should because if I'm not a Jenkins person, I was just gonna say, if I'm not a Jenkins person, a lot of those plugins look like tools to me. I know enough now that I know what Jenkins means by a tool, but it's not in the outside world. I think a monitoring tool is a tool. Pipeline would be a tool. Lots of those plugins would be tools. Yeah, exactly. The word tool is completely overloaded and dangerously close to incomprehensible unless we put a lot more words near it. Right. A JDK installation. Jenkins user understand that we are very careless with terminology. If we find a word and like it, we use that to apply to 22 different things. So we don't have to just tell another word. Yeah. And I second your opinion that terminology is very important and great. Yeah. Thank you. We're all sure that. And we can't, my thought in the writing, we need to get, we can fix, we can get more precise with the terminology, even though we're probably gonna have to use a lot of adjectives with nouns to make it clear what we're talking about. And we can hope that as other people read that enough that they'll learn to talk that way, but that may take longer. People are gonna be such swine. Some people. We'll leave Meg's quote in the recording. That was brilliant. Oh shoot. Thanks everybody. Okay. Thank you. Bye. Have a good week everybody. Bye. Bye everyone. Thanks you too. Bye bye Meg.