 Okay recording has started. Alright thanks everyone and welcome to the Jenkins documentation office hours. I've got notes here I didn't even look at the notes yet so let's take a look at those and I'll share my screen so we can talk through them together. Okay so you should see on my screen. A reasonably sized version of the office hours for today the 20th of July. Alright so it looks like we've got a question about a particular issue. And we can certainly look at that together. And other periodic meeting events. So, Jonathan, you want to give us some insight on, we can look at 2987 pretty easily. What's any further details you want to offer on periodic meeting events? Yes of course. Can you visit it please? I guess I put the link on the number. On the hyperlink on the number. I don't see a hyperlink there but it's easy to do. I guess it's here. Here I put there. It's on the document if you wish. Thank you. Because it's just, yeah, there we go. All I get has complained that it's a blank page. Maybe in the past someone has plans for it but forgot it I guess. How do I need to do it this page or just remove it? Yes. I think that for me I think that configuring the system is a reasonable topic. It's a very reasonable topic for managing Jenkins. It may in this case be too broad. And given the duration that it's existed without any content. If the day comes that we get someone who proposes, hey, I'd like to put content there. Great. We bring it back. So my guess for now would be we just delete it. Okay. There is no reference on the week about the configuration system. Oh, there's there's lots of information on the wiki about configuring the system. But much of it is expressed in managing users, managing nodes, script console, groovy hooks, scripts, managing tools. Every one of those things is effectively configuring the system. And so with that many topics already saying how you configure subsets of the system, a top level, a top level thing that says configuring the system. I'm not sure what it would say. Actually, the writer standpoint, and I'm not super familiar with this, but it might be that it should be a short introduction. There's all those specific things. But and the thing I see coming in is you can edit the config.xml file. And we have configuration as code now. And there may be some other options just sort of a high level. The specifics may be covered, but. Well, that could be. Yeah. So good. I can't tell you how long I was writing about Jenkins before I figured out about the config.xml and I still don't know all about it. Well, and there's a very to say that there are these two options and that there's some things you can do in one that you can't do in the other. And, and then to say that the specifics about configuring each individual component are going to be embedded in the doc for that component. Yeah, yeah. I think it's a good call. No, no, I think you make a good point. This could just be an introduction. I'm not sure I agree. I'm entirely aligned with your separation of which things it should introduce. I think it would introduce the concept that Jenkins is a profoundly configurable system, right? It can be configured to do all manner of things and in, in many different ways and it can be configured. And so this might, this page might introduce the concepts that are involved in the configuration of Jenkins where those concepts are. Can be UI driven, right? Can be code driven. Yes. And if it's code driven, it can be code driven through the configuration as code plugin or through the job DSL plugin. Right. And the CLI REST API and. Right. So, you know, it's like, if I'm a new user and I want to know, how do I configure this system? I don't see a hit. There's specifics. Right. There's nothing about configuring it. I like that. That's a very good point. So, so this might be an excellent place to put. And several, a few, say three or four, maybe, but not more than that introductory paragraphs. That introduce the various configuration concepts and then, then jump to details of those concepts. So what's a tool? Oh, that's an important concept. Yes. What's a plugin that's an important concept might jump to the plugins. How do you configure security or what's, what is security? What are you securing in the context of Jenkins? So I think, I think there's some. I think there's some, I don't know, I don't know what's an agent or a node. And so, so yeah, I guess, I guess this could be an intro. Or back to the history of it still is there's not all, there's never been any content placed here. If we said we will put an intro someday. And when we do, we'll bring this page back. That, that is fine as well to me. But this is, we'll have to go back to the rest API. And, yeah, that's it. Exactly. Well, the fact that to understand that most things that you can do on the UI, you can also do from CLI and rest API. All the, the idea that most configuration changes you make are going to necessitate restart of Jenkins. Okay. a fast introduction about each option of the configuration menu. For example, credentials, items, it will help you to create credentials, administrate it, and for more information, as visited on-page, something like that. I mean, we're looking at something that's more high level, just at a high level, what does it mean to configure Jenkins? That you do a lot from the UI, you do some from CLI, we've now got configuration as code. Yeah, that it is, as Mark said, that it is highly configurable, that there's very little in it that you cannot control. Almost sort of that high level. There's managing the system, and configuring Jenkins is a subset of managing. Okay, can Maggie or Mark offer some talks about the specification to work on it, to direct from my work, for example? I think so, let me, I'm gonna try to just type it in here. Let's make this. Yeah, not for now, maybe later. Yeah, so I'm just thinking that if we do it now. So that since Oleg is looking at this, I'd like to see what Oleg thinks of what we're saying. It's a good time for an issue conversation, right? Right, yeah. Or we could call a meeting and invite Oleg, which seems like a waste of time, but just see if what we're thinking makes sense to him. And let me add also, in case the board will decide to do some content in this page, maybe we can add some section about best practice. For example, in case if we started configuring, using configuration as code plugin, doesn't it make sense to switch to UI? And why is that? One or the other, yes. Yeah, if we started from UI, how advisable it is to switch to configures code plugin sometimes. I've got to grab this for something else. There is, they just came out with a new plugin that if you install and enable that, that once you do something in CASC, it makes everything else read only. So you can't go into the UI and change stuff. And we recognize, recommend that. There is another issue that could be referenced to us. Maybe fine. Oh, Mark, the fact that whatever you see on any of these configuration screens may change depending on what plugins you install. That most plugins start adding stuff to your config screens. And that was, to me, that was shocking when I first, I came from operation systems, you know, and you kind of had your operation system configuration that didn't change a lot. And then you got into all the other stuff that you could configure, but. Good, okay, yeah, that's a good point. Frequently created and extended by plugins. And configuration as code is one. Our configuration techniques might include configuration from the UI. Yeah, let's do that order here. CLI or KPI. Yeah, good, yes, our configuration from Groovy scripts. Okay, yep. System level Groovy scripts. And I'm not sure which order they should be in. So that's, we can talk to configuration from REST API calls. You make CLI separate? Yes, Jenkins command interface. Put CLI into that line because they never use the spelled out more as a pity. Okay, configuration as code plugin, job DSL plugin. So, Mark, I send another link on shot, as on shot. Okay. It's about the page that I send APR this week. Maybe give to some idea, reference idea if you can access please. Okay, yeah, just a moment. Let me fix my mistake here. Having to remember which form of indentation there's being used. Which markup language am I writing in today? Another thing, just to mention in passing the authorizations required that like not everybody who wanders by is going to be should be allowed to change the configuration. But some people might be able to change some part of it and not all of it or, I don't know, we don't want to get into real information just to alert them to that there are authorization issues. Right, authorization authentication links there. Maybe actually put out authorization pointing to the permissions that are granted on the matrix. So that kind of thing. Yeah. Jonathan, does that, is this give you enough stuff that you could start on writing something? Oh yeah, of course. I always, Mark, shut up. You don't know this about life as a writer. I guess I would write about the entire Jankin industry. There are writing tasks that are mostly research and learning and then a little bit of writing. And there's other things that's really just writing that you sit back and you've got all these details. And there's like, if somebody who's starting there's no way I can't see the forest. All the trees are here. Tell me about the forest. And it's really just a writing exercise. And a writer spots it as you did, so. Let's see. And you said, Jonathan said you posted it in the chat. Okay, so let me bring up the chat. Now, how do I find the chat in my other, it is chat. Okay, so distributed builds. Okay, there we go. Yeah, I sent a PR about this integration, but I guess the idea may be similar to this page. It's the first kind that I get on the documentation. It's just to tell some history about the introductions, some points and get to read some links to visit the specific page. Maybe that's idea to create the configuration system page. Yes, I think this page configuring the system should be, I like Meg's suggestion that it should be brief. So a relatively few paragraphs and then stop. And inside those paragraphs, it's perfectly fine. So the paragraph should introduce a few key concepts, but not too many, one or two concepts per paragraph, and have hyperlinks inside the paragraphs to the things that are related to them. So. Right, right there, CLI, script consoles, groovy scripts. Now. Impressive, yeah. Okay. But. Now, I don't know how good or bad. Oh, okay. So there is content behind script console and CLI. Good. Okay. So there is, and certainly that intro page, managing plugins, it seems reasonable that it would have a paragraph that talks about what's a plugin and maybe that's already there in using Jenkins. It would be really astonishing if it were not, but I'm not sure it is that that's so, so certainly configuring the system would have be a great excuse to introduce a plugin is this and you install plugins to add capability. And here's a link to the managing plugins page. Right. No, okay. Yeah. And also my advice would be, of course, we can make things very complex as it is already with configuration of Jenkins, but we want to keep in mind a new user of Jenkins. So attract new customers, basically. And my advice would be to keep them in mind while suggesting options for configuration. So they will not be lost in the forest as I can say. Great. But there's a lot of, I see the history here that so much of this was written by a small cadre of insiders to begin with. And they forget the very, that if I'm new to this, I don't know some of the basics. I look at the UI, I sit there and I configure and it's like, yeah, yeah, but I've got a hundred masters. I have to do this a hundred times. I wish I could just write a shell script. Why don't they give me a shell script? Well, we did. We just didn't tell you about it. If you dig enough, you'll find the docs that are good about how to do that. Yeah, okay, we're gonna, one of my bugaboos and I can see exactly the history that once upon a time there was a Jenkins and you put all your stuff there and you ran your builds on it. And there was a day when the distributed builds was probably the hot new feature. And that still shows. And today it is not a hot new feature. It's how I think our installation, you get Jenkins up and running. Now you create a node, you put an agent on it and some executors and here's how you do this. And in the fine prints, you say, if you're just playing around and learning, it is okay to put that node on your Jenkins master but never in production. But as it is, if I read through the documentation very cautiously, I go to a lot of work and I'm running my pipelines and my jobs up on my masters and then somewhere along the line, it says, oh, if you really wanna be fancy, you don't have to do it that way. Whereas we, you know, but the subtleties of the table of contents that still lasts, it looks to me like an add-on feature. But someday in my spare time, maybe I'll go back and re-hack it all. And no doubt annoy everybody in the community who's just perfectly happy with it the way it is. Okay, so Jonathan, did we cover your question there? Yeah, it's covered. Just one more question, but it's time about the Distribute Build page. Okay. Yeah, I send the migration here, okay? But in the content, there is some links that point to another pages from week to week, week pages. Yeah, because that pages don't migrate yet. There is some problem with this links or no, we can keep them quite the use, say about it. We can keep links to the wiki if there isn't a better page already on Jenkins.io. Yeah. And if that wiki page has not already been redirected to another location on Jenkins, it's not been migrated. It is perfectly readable for Jenkins.io to have links to the wiki. Otherwise, we risk that an attempt to migrate one single page will, if we're not careful, migrate the entire wiki before the pull request is done. No, so it says it. Okay, that's it. Thank you. Okay, so I think we've covered issue 29E7. Other periodic meeting events. Tell me more about that question. Yeah, that question, it's about, for example, we are in the docks of hours, all right? This meeting, yeah. For example, it's only the proposal to work on the Google season of docks or this kind of meeting exists before the Google season of docks. I don't know the history. It only came into being because we felt the need for it in Google season of docks. It will continue to exist as long as people attend and there are interesting topics to discuss. We won't cancel this meeting until we find that it's just not meeting our needs. No, okay, because I'm afraid to, maybe because we tested after the Google pronunciations about the second call writer, there is no more meetings to ask questions. What's the idea? No, no, quite the opposite. The intention of office hours is really to allow us to help each other. And we'll keep doing that as long as there are people who ask for help and people who can offer help. Now, okay, so. I just got hired to a new job today and I'm meeting Jenkins for the first time and I'm a writer and I start reading the docks and say, gee, I'd like to fix some of this. Do I quickly find out that there are doc office hours every week that I could attend? Probably not. What we hope you'll find out very quickly is that there is a link here, improve this page. You'll click it and it will take you right into offering your improvement. But I must say, I'd like to know what's going, I mean, this happened to me when I first started actually, Mark and you were a colleague and they still didn't know. I had no place just to look in general, what, you know, to know who's doing what with this and what's the system and. Well, and so overview kind of things. You can certainly look at the doc SIG, the documentation special interest group. And it gives you a guidance to, hey, here are the meetings. It talks about the special interest group. It does not, however, mention office hours. So it's a good point that we may want to put an action item on me to put an entry. Oh, no, it does mention it. Sorry, it does. Okay, each Monday at 2200 UTC. So yes, it does. And there is also under community item. There is events link, I think. And on the events, it's event calendar. There is docs, I was also mentioned there. Okay. I hadn't tried searching this, maybe. I'm not sure if it is possible to search. So somehow, calendar. Yeah, so there are at least two locations where it's described. I'm not yet persuaded that we could ever put it in enough locations that a new contributor would immediately find it. But that's not a big deal. The reality is they will find it one way or the other either by a question to the Gitter chat or a question to the Docs mailing list or by somebody just telling them, hey, here's this office hours you could attend. Did that address your question, Meg? Sure, yeah, just a random one. If I go in and say I'd like to improve this doc, is my name associated with that, right? It will be, yeah. So when you submit- Do we have any sort of thing that says, hey, thanks, this was a great addition. Did you know that we have a weekly office hours for documentation work and you're welcome to join anytime or something? We do not, that's an interesting- Is that too invasive, intrusive? I don't know. It's actually not. The GitHub, it's an interesting idea, a ways to incent writers to continue contributing, right? Right. And there are, I believe GitHub offers some, automatic replies, et cetera, that are not currently enabled. Another of course is, and this one has been astonishingly effective, do a hack event, our next will be Hacktoberfest. And send, okay, I'm gonna use the word swag and I'm not sure that the word swag is a reasonably well understood. Send marketing materials. What's a good reasonable word for swag, Meg? I don't know, it's kind of toys, but- Yeah, so- I don't know for people who are non, for whom English is just, I'm also constantly amazed at the English words that non native English speakers are familiar with. Yeah, so Jonathan help us here, or Vlad either of you- Do you know what we mean by swag? Does the word swag say anything for you? Yeah, it's my gift. Okay, yes, yes. You said it brilliantly, small gifts. Thank you, that's perfect. That's much better than swag. Thank you. The first time I saw swag and the mail from Jenkins, I did understand you. Right, exactly. It is very, that's even worse than being not really, not terribly English. It's very much marketing speak, right? It's not even technical English. It's some bizarre word from somewhere. Okay, so that's our, this has been our most effective incentive, the encouraging people to hate, tweet your, tweet the package you received from the Hackfest. And that has generated lots of positive, positive noise. Right, but how do people, does everybody who knows that there's a Hackfest coming up know, I mean, would be interested. Like that would be a thing for GitHub to send everybody that's contributed anything to say the docs in the last year might get, I'm getting too much Netflix mail right now, but it's starting to, you know, it's finished watching like a six season thing. I finally finished it in the next day. It's like, we hope you enjoyed it. Would you like to watch it again? And you might like to watch these other things. But I'm like, you know, okay, on the one hand, you're annoying me sometimes because, but you know, that's not a bad idea. It's like Netflix cares about me. Yeah, and I, that's a good question. I'll have to do further investigation. I don't know of any obvious, any techniques. I think GitHub actually does have a way to encourage further engagement, but I haven't studied it enough to see what we could do with it. It's just, I've studied it around other open source communities. This is one of the nicest ones, but from the other ones, when I come into this one, I'm not real anxious to jump in there and let somebody start throwing things at me, you know? And it would, if you, you know, if I did something little, something that they've got my name to write back and say, hey, you know, we're glad to see you here. Would you like to do more? Jonathan, did you have something more to say there? You may have more information. Yeah, it's a good idea about the talk to the magazine, talking about the, for example, in our Jankphile page, we have a link there to World Communities that work with Jank. But for example, in the last October hack fest, I participated the first one. No of my friends know it's about, maybe send a mail for that community links or some pronunciations about the next event. We increase our number of participation. We already have the links to the groups or their meetups. Something, Mark, you and I should look at this sometime when you have a few minutes as we can fix it fast. In our Jenkins Fundamentals class that we offer, it's paired down, it's now just about an hour class. We took creative, but we do have one section there about contributing to Jenkins. It's pretty short, but we might wanna add just a slide or two, we sort of point them to stuff, but say if you're interested in this, there are office hours for different groups and all this sort of stuff. There might be just a slide there that that would open up. We're getting a fair number of hits on that class. Good, okay. Do we care that that syntax makes it sound like the Jenkins Fundamentals class as CloudBees free? Okay, let's see. Don't you hate writers? There we go. How's that? Yeah, that's brilliant. See, my use of prepositional phrases in English is catastrophically broken. I will continue working on that probably until I'm dead, if so broken. Everybody is, because we talk that way. But every sentence I write, I reread and usually rewrite then because I go, oh no, that's not what I meant. I just put things all in a jumble, yes. Great, okay. Well, and maybe kind of related to this, is it possible to substitute swag as incentive for taking the spade, paid versions of Jenkins Fundamental classes, certified classes, open by CloudBees, something like this. Yeah, right. Consider incenting with courses, with online courses. Certified, whatever. Yeah, make use of it. Did you say something about paying for them, Vlad? Was that? Did you say something about paying for the classes? Well, I haven't explored it very in detail, but my understanding that CloudBees offers a lot of really nice free fundamental classes, but there are some like classes which allow certificates and some of those certified classes require some payment, as I understand. So study for right now, for all of the classes is free and I think it's probably gonna stay that way, but right now all of the classes are free to take for self-study. Oh, great. Separately is, well, and these classes actually relate, if you understand the material in a set of these classes, that pretty much qualifies you to sit for certification. Now, the certification exam itself comes with a cost and it's run through a third-party organization, although if you're spreading the word, because of COVID right now, the price is discounted and people can take the exam from home, which is a whole lot easier than having to go into the center. Thanks for clarifying. So yeah, if you go to CloudBees University page, there is a little blurb, it looks like class, but it tells you what to do if you want to get certified and it tells you what the classes are and what the whole process is. So, but the classes themselves are free to you at any time for self-study. Great. Thanks. And under constant improvement, so. And make you had said right now, all the certification prep courses are actually no charge? They have, yes, those, and those have been free charge, no charge for a while. The one class for which there was a charge was the Pipelines Intermediate class, which I think may be about to be broken up into smaller modules anyhow. And I suspect we made it, we made everything free because of COVID, and but I suspect that we will keep it that way. CloudBees general thought is that we're much more concerned that people learn how to do this stuff and do it right, than we are making money out of training, so. And may I ask to like clarify one question, which I'm not quite sure that I understand, really the difference between CloudBees version of Jenkins and community version of Jenkins. Is it complex question, or if it is not so complex, well, maybe. I'm with Dehulak, I'm with him. Mark, do you wanna take it? I am happy to take it, it's a, that's a, there are many, many differences between them, and so it's a lot of different areas. So for example. But I think it can be summarized quickly, Cantot. Let me do the high level summary, and then you do the brains. Go for it. Okay, CloudBees, the CloudBees product is totally based upon Jenkins, and we continue to contribute heavily to Jenkins. It is customized for enterprise, for special enterprise, meaning large, large configurations. The big feature that you get is something called an operation center, which all your masters are attached to, so you can sit on your operation center and connect to all of your masters, and download stuff and sort of, sort of not as much as I wish, but sort of manage all your masters from one place instead of running around the place, trying to find every one of the 100 masters. And then there are a number of proprietary plugins that are offered that have very great value, and theoretically, I don't know this all, but theoretically things that you need in an enterprise more than a small, you know, a lot of things for, I don't know, old ones, long running builds, and there's cross team collaboration, a much nicer feature, for instance, if you have a plugin on one master that you want to trigger a plugin on another master, a very nice interface for that, and a few things like that. So if you're really small, you know, if you're a little shop with three developers, CloudBees probably isn't much use to you, but as you start to get bigger, CloudBees has some very nice features in it. More sophisticated authorization through roles, and which now there's an open source roles, but it's not as robust as the one that's in CloudBees. Now, Mark, actually, Mark, you go and do more details. I think you did great. Oh, the new hot one, geez, I've only been writing on it for the last four hours. For CloudBees, for configuration as code, that still works, but with CloudBees, you get the ability from the operation center, you can configure all your masters using, you know, CloudBees as code. So you get the interface and it includes, you can do plug-in management for all of your masters through configuration as code on CloudBees. So that sort of stuff, but it's mostly features that extend Jenkins in ways that are very useful if you've got a very large installation. And this class is provided by CloudBees. They are targeting mostly CloudBees version like large installations or the power booths. We, well, frankly, most of our CloudBees customers start out running Jenkins. And at the day that their top IT comes in with a knife pointed at his heart because he's so tired of running around trying to find all 100 masters every time he needs to do an upgrade, they start talking about putting in CloudBees so they get some control over it. In fact, when you boot up CloudBees Core or it's about to become CloudBee CI, we're renaming it, but when you boot that up, the first screen you say, you get says welcome to Jenkins. So this is why we do the Jenkins classes and the classes are clearly marked as to whether they are a Jenkins class or a CloudBees Core. But if you are brand new to all of it, you better take the Jenkins classes before you take the CloudBees Core. Because in CloudBees Core, you learn a lot of fancy extra stuff you can do with agents, but you don't learn what an agent in a node is. We assume you know that. So the security settings, a whole bunch of that stuff is just the same, although slightly different ramifications because you even have the option, you may have masters attached to your operation center that is still self-managing that you don't control from the operation center. Or you can set on your operation center, don't let any masters have any executors and nothing you do on any of those masters will put an executor on any of them. But it's highly configurable, of course, it's changed. Two geeks, three opinions, we support all. Thank you. Other topics that you'd like to discuss? Yeah, just for get the same way. And the CD foundation, CD foundation where it gets apart. For example, Jenkins and CloudBees, the CD foundations are sent together in the same post. CD foundation. Okay, so I'm not sure I'm understanding your question. Where does CD foundation sit in the hierarchy of things? Yeah. It gives a CloudBoy, CloudBees, yeah. That's definitely one. Between it's above, it's on the top. Okay, yeah, so that's a good question. So Jenkins is a project, right? It's an open source project, but the continuous delivery foundation provides a legal entity, so that the Jenkins project can enter into agreements, legal agreements, as an example, code signing certificates. A code signing certificate organization does not want to issue a certificate to an entity which does not exist. It would be far too easy to steal or to make a deal with the entity. To mislead people. And so they demand that there be a legal entity. The other is receiving donations, processing, well, in our case, processing small gifts to contributors. They did all the shipping for us of the things from the Hackfest. And it was very, very nice because prior to them, we've done all sorts of heroic, crazy things of having people do their own shipping. And it's much, much better when somebody who's really good at that knows how to do it. And it does, I think this is true, correct me, Mark. Before there was CDF, Jenkins did, or CloudBees did all of this stuff. And then there were getting to be times when the financial people, it was like something needed to go out for the open source community at the same time that something needed to go out to CloudBees customers. And needless to say, the financial people were saying, they're giving us money, they get priority, and the community is saying, but, but, but, but. So it was a nice, it's an argument that we should not be having on a day-to-day basis. So this gave us an organization who was primarily charged with the care and feeding of the open source community, independent of CloudBees who tries to take very good care of their customers, hopefully succeeds. Yeah. Now, in terms of a historical detail, the Jenkins project actually came into existence in 2011 as a result of a copyright dispute with Oracle Corporation. The preceding project was called Hudson. And it was the copyright for that, the copyright for Hudson was owned by Sun Microsystems. Oracle purchased Sun Microsystems and the Jenkins project or the people who were developing on the project that was then known as Hudson started trying to understand what it meant that it had been purchased by Oracle. And Oracle became somewhat determined that they were going to strongly assert their ownership of the Hudson copyright. And that was the catalyst that then caused the Jenkins maintainers to say, we are renaming the project, what was Hudson will now be Jenkins. And thus, because of that, the Jenkins project is sensitive to ownership of copyrights. And we will continue to be sensitive to it. Prior to continuous delivery foundation, the copyright was held by an organization called Software in the Public Interest. So copyright ownership is a big deal for us. And we make sure that we know who owns the copyright and that it is an illegal entity with the right defenses. Okay. And another bit of trivia is that Koshika, who is the person who originally wrote Hudson when he worked for Sun. And he's, I don't know if you've ever met him. He's very impressive. He's very, just because he's so gentle. Then he always said, I was just lazy. I just wrote this. I was tired of doing the same stupid thing over and over again. And that's the beginning of Jenkins, but he is one of the co-founders of Cloudbees. And until very recently, he was with us, but when the CDF started up, he went to CDF and was that. And now he has now established his own company doing something that is related. Cloudbees is one of, is a heavy investor in his company. He continues to hold a very large ownership of Cloudbees. So it's very incestuous, but, you know, but so KK is out there, but KK went to CDF. And I would say, Mark, he stayed there long enough to make sure that they were solid because wherever KK is, has a certain panache because it's KK. And... Did that address your question? Right. I'm sorry, I love that. Yes, yes. I love history now. Everything makes sense, thank you. It's a good, it's important point to know the thing. It is something that happens. You actually had a couple of things that I didn't know. This is not written up any place. It's actually on... Oh, of course, of course it is. It's in blog posts all over Jenkins.io. But I agree, there isn't a definitive history of the Jenkins project anywhere that you could find as a single document that I recall. Yeah, but it strikes me that like, because we have been very careful at trying to keep our Jenkins courses separate, but there is a question. This is a Jenkins course. It's offered by Cloudbees. What is the difference between what Cloudbees? There ought to be, and there was some other stuff there once which got terribly cruxy and we lost it, but it ought to be out front. It's like, what is Cloudbees compared to Jenkins? So, I can do some work on that, so. Any other questions? Just, I wanted to a little bit address the section called tools, using tools in our documentation. And specifically how it is related to configuration, which we touched a little bit in the earlier in this discussion, specifically of poor configuration as code plugin. There is a section in, I'm not sure if section is correct word, but there is part of configuration as code called tools, which you can specify different tools like JDK, Python, and so on. So, the question is, is there a relationship between documentation, our documentation tools section and tools section in configuration as code? There certainly is, yes. And yeah, let's see if I can bring up something to show an example of it. Here we go. Okay, so if we look at a configuration as code definition file, here's my Jenkins.yaml. All right, and we'll find in this thing, some tools referenced. Like this one, all right? So, here is the tool keyword. Let's see, we should make this more readable. There we go. And there's the ant tool, and there's its definition, where it's downloaded from, et cetera. So, very much configuration as code does support the notion of tools. I'm not sure that was specifically your question of that. So, ask your question again, and let's be sure we talk it through. Well, I just trying to understand how what is the best way of using tool section in configuration as code while addressing documentation, tool section in documentation? Because when I'm trying to go through tool section and documentation, I'm trying to implement, for instance, using configs code approach, which may be attractive enough to new users. To make it simple. And I'm just trying to find out the best approach for me to navigate through these complexities and for us. And that's a very good question. So, I think what you're asking is, how do we guide new users to success and still preserve the knowledge that is needed by advanced users as they go well beyond what the new users need? Is that a fair way to rephrase what you were asking? Yes. And in case if I'm configuring my initial instance of Jenkins, and I'm using, trying to install some tools using this tool section, oh, is it appropriate way of doing or should I go through plugins.txt file and install different plugins? Well, I'm not sure if it is possible to phrase in written sentence very briefly, but just trying to explain what I mean by that. So, listen. Oh, go ahead, I'm sorry. No, no, Meg, I was going to give a two sentence and then defer immediately to you. So, go right ahead, Meg. Okay, well, I was going to actually respond with a question, sorry. Because this just hit me. Back to that, you're managing Jenkins page when Jonathan is done fixing the configuration page, this needs the same thing. Managing tools is a list of the tools that are there automatically. But, and now here, and I actually have, this is not my question of things that I need to learn that I, you know, I'm getting to the point guys where I know a lot of things and then there's the basic things that I don't. But when I'm in the configuring system page, I can configure some tools up there, what version of Java or MAP and not all this that I want up there. I can configure those in my agent or I can in my pipeline call and say I specifically want this tool and load it from here and bring this tool in. Now, what is the relationship of all these methods? They have, they all have their place. I believe Mark, from listening to our favorite could imagine that configuring the tools on the master itself is not the preferred way in most cases, that you want to configure them but it's more efficient to have them on the agent or in the pipeline. I'm not positive of that. And I don't know where to look. I know who to call up and get his opinion on it and he's pretty senior, I would take that. But I don't know where in the documentation I'm going to find the avuncular advice. As I go through those configurations, like if I want to use JDK 11, I'd better get that on my master. And I don't know, or, and it may be that I should put it on my master and then use the version that's on my master to put it in my agents. I don't know. But yeah, is that which a little bit of what you're asking, Vlad, is that there's all sorts of places where I can define my tools and why? Right, and at the same time, I'm just trying to figure out the simplest approach. So again, it was consumable by a person who is trying to get an understanding. So in case it will be simple enough. It's like, it's one of those things where I don't, I think the options are there for a reason. For example, if your pipeline is building an application that runs on desktops and androids, you want to build it and then you want to test it. You're going to have separate stages for testing it and you're going to test it on androids and you're going to test it on Linux and Windows and whatever else you want it to run on. So in that case, what's on your master is not necessarily what you want because, you know, and you want to make sure it works with JDK8 and JDK11. These are all things that are tools. And I believe you do that by making agents that have the specific thing you want to test for. The old fashioned way, and we're all old enough here to remember when there was one group who coded this application for desktops and then there was a hot new group who took that same thing and made it work on Android. And then they did some stuff on Android and then we had to hand it back to the old group to run on the PCs. But today the right way I believe would be to code the application to run on everything and then write your pipeline so it gets tested on everything correctly. And that's going to mean defining your agents. Now, if you're doing, you know, if you're going to do a cookbook for your grandmother for Christmas using Jenkins, you probably don't care. You're going to use one version of every tool and you can put it on your master and go ahead and build it and put a red ribbon on it and your grandma will be just happy as a plan. But so I think it's one of those things I think, but I think there's a lot of subtleties about the reasons to use different methods for defining the different tools, am I correct, Mark? Yes, there are lots of subtleties around different methods and different tools. And every method has times when that is the best one to do, right? Right. And if I am a new user who wants to get quickly to this understanding rather than choosing one because it looks like fun and finding out six months later that I did the wrong one, I don't know where to find a little overview that tells me you can configure tools here and here and here. Well, and so Vlad, I think that's why. The configuring tools is challenging because of the many different ways that can be the exact right way to do it for your particular use case. Right. So this thing, this page talks about the classic way of doing it where I have an installer that will automatically install onto my agent when I need that tool. So think of that as the agents are general purpose and don't include tools until they need them. In the Kubernetes. Wait a minute, where in this page does it tell me that I'm putting these tools on my agents? It doesn't, but it would if this page were written. Yeah, before I made an agent, I did configuring system and I'm just finding all my, I put all my tools there. So when I done, I mean sarcastic. Yeah, yeah. Yeah, that's what exactly what Jonathan pointed out with the config, what we came up with the configures. This thing needs exactly the same forest. Right. And it doesn't have to give every corner case but give sort of why you would define them here, why you define them here, why you define them there. And that's a not important point that we need to take care of. For example, in the same page here, we have this tutorial section that's speaking about using build tools. So we need to try not to repeat ourselves in different page. Yes. You find it and the tutorial about using build tools. Okay. So if the first one, it's just an introduction, maybe more technical details and go into the tutorial section, how to start it, how to configure it and how to use it, use it in the way one, the way two and go on. Exactly. But in the introduction to managing tools tells you that there's different ways to do it and it depends on each and yes, not the detail. Again, forests, not trees. We're, the more I read of our doc, we're really, really, really good at trees. And if you want to find the forest, God bless you. If you were as wise as Mark and work at this for years and years, you will wake up one day and you will see the forests but we could be more generous with our new users. Well, we need to add section, how to become wise as Mark Yeah, there. Right, that's what we need. Oh, that's it. And the answer there is make a lot of mistakes. That's the way, wisdom comes from a lot of, so okay, so the complications, what you're really saying Meg was that the techniques for tools, for tool use depend on agent type. Depend on agent type. Are they general purpose agents or specific or tool specific? It also depends on if they are ephemeral or not. Yes. So if the agents disappear after every build, it also depends if they are, for example, Kubernetes or not. So Kubernetes and I guess Docker or none of the above. And the two, okay, everybody else here's Meg is ignorant. The tools that I define on the master itself through the configuration screen, configuring the system, are those just for builds that I run on the master? No, no, they are installed automatically on agents on demand. Okay, so automatically every agent that I create on that master will have those tools. With the caveat, for example, that you won't use those if you're on a Kubernetes agent because on a Kubernetes or a Docker agent, you just say like it did in this example, you say which image you want to use and it will go get that image for you and use it. Okay. So here I didn't have to do anything on the master at all to tell it how to find Maven. It finds Maven by pulling it down as an entire Docker image. Aha. And so if all of my agents are Docker images, what I can figure on my master's tools is of no use whatsoever. That's right. You said it briefly, you didn't need to configure a single tool on the master if all you use are Docker agents or if you use Docker and Kubernetes agents. I guess we should say container agents. Right. There's another new container type that's out there too because of the key, I don't know. But so we should be saying containers, not just Docker. Yeah, so it's really containers or not. Right. And usually in the, it's much more common if you're doing ephemeral agents, you'll do containers because most of us are too impatient to start up an entire virtual machine for only a single use. Right. Okay. So we have hit our time. I propose to conclude here any other topics before we close this and this session. By the way, what is this list here that we just wrote? It's full of good stuff, but what's it say about it? This is the Docs Office Hours notes. Okay. And no, I mean, well, just beyond that. Do we have an action item for any of these things or? I had not put any action items in my intent with the office. Like what are the differences between CloudBees products and Jenkins? This is great. Where does, maybe it doesn't need to go anywhere. Are we, for next week we can decide if this and it needs to be actionable. This one decidedly does not go on Jenkins.io. Right. This is describing those differences is a CloudBees responsibility. And therefore CloudBees.com can worry about those. The Jenkins site doesn't need to worry about this really any more than we worry about what are the differences between Spinnaker and Jenkins. Right. We've got enough. Yeah, I'm going to take that. I will grab that one and do it. But continuous delivery. Now that might be a little bit, that's a little bit, whatever, the tool stuff. I guess that. Do we have it? This one's already on Jenkins.io. This kind of information is already there. Okay. We did what needs to happen to the configuring the systems. This using tools, that should be put into an issue for that. Right. Just like we did with 2987. Right. That could be the other information could be captured. Yeah. Okay. I just want to make sure it was good stuff. I wanted to make sure we, it was a fun conversation. It's like, does it have any future? All right. Okay. I will post a recording of this session. Thanks everybody. I'm going to stop sharing and thanks very much. Enjoy your day. Terrific. Talk to you next week. Bye-bye.