 Welcome to Jenkins Docs Office Hours. It's the 8th of March. Let's look at the agenda. So, She-Code Africa Contributon coming in April. I need some discussion. Site search, Docs Roadmap Inventory, and I've got one that we may want to take a look at. I haven't looked at the data myself, but I owe the community a summary of the Contributor Summit retrospective for tomorrow's governance meeting. So, it may be worth looking at that. I'll see if I can find it, and it would be completely unvarnished, and the danger is if someone said something really harsh, they may not want it recorded. So, let me do a quick look just to see if that's a safe thing. Here we go, Summit retrospective. First, we've only received 11 responses. So, that's not that many responses and good. Okay. Good. Yeah. So, and it's safe. That's good. So, we can look at those and extract some data. So, yes. Okay. All right. Okay. So, anything else you want to put on the agenda, Meg? I know. I'm good. All right. So, the She-Code Africa Contributon, not much changed since last time. I have not heard anything on sponsorship yet to finalize it. I've reminded Alyssa Tong that we're depending on that, and I think she's going to do some further work there to try to get that sponsorship. Oh, good. I've got to submit the application. That will be several days yet before I do it. Computing resources we know about and skills required. What we need now is a separate document with a list of project ideas and mentors with project ideas and mentors. And on this one, Meg, I think you're still willing to be a mentor if it's early in the morning Africa time. Yes. Okay. Good. All right. Not early in the morning, my time, yeah. No, no, that's right. Well, it's very early in the morning, your time, like midnight. Oh, no. Did somebody say that 6 a.m. is late night to her not early morning? I thought, yeah, that's me. Got it. Okay. Great. I'm just warming up at midnight. Right. Understood. So, that's really the extent of that topic. Now, next topic for me was site search. And I haven't looked at the latest metrics because I don't quite know how to get to those metrics. But what you can see here is there really is a search and it works. All right. And so when we say pipeline, now it's currently biased a little bit towards the extension points documentation because there's so much content in them, but that's actually relatively low value to our readers. So, but you can see that the words appear, it finds them and there's a tutorial. Okay. Extending Jenkins. So there's a developer tutorial. If we look at tutorial here, there's a tutorials overview. So the site search is working and it's much better than not having any site search. The challenge is things like this one, if I search for get here, the results that come back or GitHub are all about the extension points. And not all about, that's good. Okay. So GitHub forked repositories. Well, see, and that's still not as useful as, for instance, if it took, my idea would be it would take people to the solution pages where there's a GitHub solution page, right? And we haven't, we haven't, and I don't know that we know how yet to change the prioritization because those extension pages, while interesting for a developer are not terribly useful. It's, they're less interesting, for instance, than even the pipeline steps reference. You can see, here's an example. Yes, this is an implement an extension point has no known implementations. No way should that be top of the page lists for GitHub. There are lots more interesting things on this thing than that. And if I wanted that, I would be searching for pipeline extension. Well, you'd be looking for extension points. Yeah, and extension points are really, that's an, that's a very important concept in Jenkins certainly, but it's a developer concept, not a user concept. Right. But the Algolia search is fast. It's the suggestions that they offer are actually quite good. Let's see if we do help. Yeah, so, I mean, you just see, they get it right to you and it appears in context. So we just need to find ways to tune which pages are returned so that we can say that extension points are the lowest priority page to return. Okay. And the plugin site search is, we're still tuning it as well. It definitely works and works quite crisply. It's very, very responsive. The challenge is that it's not apparent that it's always indexing all the words on the page. So for example, if I click, if I were to look for system configuration variables, which is certainly a valid string, my guess is you won't find it. And, you know, we've, this one because we've done the implementation ourselves but are using their indexes, we expected that there would be things that were not perfectly well-behaved. Right. So what if I search for a specific step? Let's see, like with credentials. Yeah, that's good. Don't think you'll find that here. Yeah. Because that is a step that's in a plugin, right? That is. Now, if I look, if I go here, so if I go to say any one of the other pages, one of the pages that then will show the search box there and do with credentials, yes, now I get it and the top hit is exactly the right one. Okay, good. So in that case, it's very, I say, ooh, I would like to read about the, what's a good choice for another step? How about the PowerShell step? Here it is. And very, very quick, right there or maybe the JUnit step. And JUnit has, yeah, there we go. Just for yet, search for inclusion pattern while one word. Inclusion pattern. Randomly picked. Inclusion pattern. No hits. Interesting. So that's in that junk JA Coco plugin. Oh, okay. That we had a problem. There may be a problem with that plugins documentation that's not found. Well, so here's the, here's definitely the documentation and there is the word inclusion pattern, but it's deeply embedded in the body of the page. Right. I was looking for something because I thought that was also a common enough string that we might have multiple plugins that had a step called that, but... Yeah, so the heading at least is found. How about Artifactory Upload? Yeah. Okay. Oh, that's interesting, you know. So on the strong positive there, we've got much, much better access to keyword-based search for pipeline steps. Right. Now, unfortunately, that still is just showing the documentation that exists for those pipeline steps. So this example is a good one to highlight. Gives us no real help on how to use the Artifactory NPMCI step at all. Mm-hmm, but it... But remember when, well, I think you filed something for yourself that Jack Coco or whatever code coverage, when you search for code coverage, it didn't find it. So I wonder if there is something wrong or something weird about that actual plugins documentation. I would be surprised, but let's see if code coverage... Interesting, yeah. So there's the phrase code coverage report. But it's not in the top five chosen, yeah. And I don't think there's anything particularly wrong other than it's the changes that I'd submitted as a pull request have not yet been released. Ah, yeah, okay. So the additional help that has been created hasn't been released, but this term I would have expected to find it and... What about coverage report to match the mainline of it? Yeah, so, yeah, coverage report, no, I don't think that finds it either. No, let's go back to coverage report. Okay, coverage report. So there's GitHub coverage reporter. Ah, Jacoco plugin is there. Oh, it did find it, okay. It did. It wasn't top of the list, but it did find it. But yeah, the tool looks like it's fabulous. Yes, yes. And with no work, it's certainly a whole lot better than where we were. Oh, breathtaking for yourself. We could do some amount of work with our materials to manipulate the index the way we want to. I assume so. That's when I've still gotta learn more about it because one of the nice things that this was absolutely impressively easy to add because it uses tooling from Algolia to do almost all the work. Yeah. So because of that, Gavin had it added in less than a day and it was maybe a page of code that he added to integrate it with all the dropdowns, everything. But I'm not sure it's got the same level of tuning capability that this one does where this one he added lots and lots of JavaScript code to integrate it. And, but I think it also is much more readily tuned then. It's one of the things I would think about, do we have the concept of say a deprecated plugin or we do really, do we? Yes. And so if I would, is there something that we can search for that would put that up at the top and does it? Sure. Let's find one. So let's find a deprecated plugin like I think there's one called, let's see, what's the, I think it's called FindBugs. Let's see if it exists. Yeah. Oops, nope. So FindBugs may have already been removed. How about let's just look for the redeprocated. Okay. So here's one. This plugin has been marked as deprecated and then there are others like that. So now how do we, yeah. So here we go multi-branch project. This one is definitely deprecated. Okay. And we've done that in the title. So if anytime, anyway they get to it, they'll know that. Well, and so this yellow box here, this box of the yellow background is actually automatically added by the plugin site based on, I believe, a topic that is here or somewhere else that says there's some database that says this plugin is deprecated. Oh, cool. Okay. It's the same technique we're using for adopt this plugin. Oops, now I gotta find adopt. That's interesting because there is definitely a plugins up for adoption, but I don't remember what the search term is. There definitely is a way because I've seen it before. Jenkins, let's see. Here we go, adopt a plugin and then it says, here is the link. I don't see it. Oh, list of the plugin for adoption on the plugin site. So here it is. And this, oh, oh right, okay. It's looking for labels adopt this plugin, whereas if I type that in here, that's different because it's saying query equals instead of labels equals. Aha. So here all the plugins that are up for adoption there are right now 113 of them. Do people ever actually go out and adopt these things? Oh, yes, yeah. I just, I offered to adopt one just recently myself and there are others who have been doing adoption exercises. They've been offered to adopt. So yes, absolutely. Coolness, okay. Cool, so are we decided that we're gonna go forward with this and we'll just do what refinements or are we still considering other options? I think that for me at least, I think the decision is done. This has been such a positive experience. I cannot imagine us. Now I have not checked the Chinese site. That's an interesting one to check. Okay, the Chinese site does not yet integrate the Algolia search. And I assume that they may need some additional help to do that integration. I haven't, I'm not skilled in Chinese. Don't know how to check it, so. Yeah. Do we have other languages as Jenkins, how? Well, we have, in terms of the website, only Chinese has been translated for the whole website. Well, you could shake out an Italian site. No, no, that would be an abomination and we would not do that because I am certainly not a native speaker. They would laugh at that and say, could you please just give us English? Well, but you could test it. Sure, sure, but that's, yeah, I don't think we need a test. Translating web pages certainly can be done, so. Right, right. No, I was just talking about testing how the search worked. Oh, I see what you're saying, got it, okay. But I know, some years ago, we were localizing all of our developer doc and our developers from like Europe were saying, hey, if I'm a developer, I have some English competency. That's all I want, so. Great, okay. So I think we've got that piece settled. It's assumed we're continuing with Algolia, refining and improving and still need a way to reduce the priority of certain results like extension points. Of course. Yeah, all right. So I don't have anything to offer on the docs roadmap inventory and proposed doc structure. I also don't have anything to offer on the docs. Yeah, that's docs roadmap in general. I have a tiny bit more of a question than anything, but how do we know whether people, when they go to the doc and read them are able to learn what they need to learn? Do we have any way of measuring that? I don't, well, I guess we've got some possible approximations in the Google page statistics. Not really. Let me, I'm thinking about this at the same time, of course, we want to modularize our training materials, which I have mixed feelings about, but it's obviously sank or sank project, so I was looking at it. So I'm looking at the pipeline materials right now. And I'm saying, if I'm brand new to Jenkins and I'm trying to write a pipeline, our training, and I've looked at the Jenkins doc and it's pretty much the same thing, all the pieces are there, but there's nothing that actually tells me how to do the content. It's pretty good on how you get it configured and get started with it. But just to say, you're gonna have a bunch of steps. Now, if you're using Maven or Gradle or something, it may be mostly or scripts that you've written, maybe a bunch of SH or bat scripts, steps that just call all this other stuff, or here's these steps that interface with other software. And there's nothing that sort of paints that big picture. And I suppose, I mean, it took me a long time. I'm starting to see it now, but I've been rereading this stuff for three years. And it's like pedagogically, I'm realizing just a few quick sentences might guide their brains faster. But then it may be that if I'm the sort of person who knows enough to do a pipeline, that this is all just obvious. I have the reference, but, you know, but we don't, we sort of say, well, here's the steps reference, but I even, I went back and noticed like at the very beginning, we say Junit, and we don't actually hit them over the head. Junit, Junit's a third party. It's some other software and there is a plugin for Junit. And in Junit, you get all this stuff and links to it. You know, let's go look at it. And now let's call it with Blue Ocean, et cetera. So I don't know if we need that. And I mean, for the training, I think we definitely need it if they're bothering to train, we'll take them. But from the documentation, do we, and there's all those tutorials, but those are all very sort of specific cases. And again, I'm not seeing the big picture of, you know, here's steps and, I know Darren's made a lot of passing, like when we were talking about conversion as well, if all your freestyle job did was call a bunch of shell scripts and it's probably good that an awful lot of pipelines pretty much just do that. Right. So I don't know if there is work to be done on that or if that's just the anal retentive writer who doesn't know enough to recognize that what we have is brilliant. So there, but I do have that thought. And another one that I'm feeling, and this is both for me for the training in this, I'm feeling some need for a big unit that is comprehensive about agents. And what I'm split a little bit about is whether we have one piece that is for both administrators and pipeline developers. It's one of those things where they do kind of intertwine rather a lot because if I'm a pipeline developer, it may be that I'm gonna tell my administrator to set me up some agents that have these capabilities and put a label on it and I'm just gonna call those. Or it may be that in my pipeline, I want to call Docker and tell it what to put in mine or whatever. But I see nothing that puts that all together. I'm still trying to figure out all of it and that there are all these different types of agents, all that work, but different pros and cons and ease and complexity and then permissions, who do you want to be able to create and destroy agents and Kubernetes agents versus Docker agents. And I don't know if that's a project is I'm sort of trial ballooning here and once again, parasitic on your brain. But then it's sort of like, what do people need? And I find the reference material that pipeline reference is just hard to read and hard to find anything on. I agree. But I don't know what to do about it. I want man pages out of it, but I've thought about it. I don't even know how to structure man pages, but so I did say, I think about this a little bit. I don't even have enough to write it down. So that's, and that's enough of that. I just want to throw that at you and you can mull on it when you're on a bike ride if you have nothing better and. Good, thank you. Yeah, so I don't have any great insights that I think you're right, it would be wonderful to have links from inside those pipeline step pages to the thing that they are supporting. Your example with JUnit is, okay, here is a link to the JUnit, a good JUnit tutorial that will take you through things related to unit testing and Java. Right. And oh, you're doing coverage. Now here's a link to a somebody else's tutorial on coverage. And oh, you're reporting coverage. Well, here's some things on code coverage. Oh, you're doing static analysis where you're looking for bugs in your source code that can be detected by compilation level analysis. And spot books is that tool. And here's a tutorial on spot bugs. Yeah. So yeah. Even apart from the tutorials is just something. Well, I don't see anything in Jenkins. I mean, I've got my little soapbox sermon at in Jenkins fundamentals, which I think nobody's reading, but about how important testing is in all the different levels. But I don't mention test code coverage. I don't really, I'm very vague. We've got unit testing and regression testing. I think I flip with, you know, user testing, which you can't really automate. But even something like, you know, all of this stuff, I don't mention code coverage. And even, even something that briefly says, you want to test for code code. You want to check for your code coverage. And here's, here are the plugins that can do that. Here are, or even just, you know, a list of plugins. If you're trying to improve your testing, here's some things that might help you. There's like sort of none of that put together material. It's all there. If I look and look and look and think and think and think and I'm brilliant. And maybe that's not a problem. Although I would think, I would think that actually it probably would be a great, a great thing. Imagine if you, if you will, what would happen if we had that kind of information and then you used it in the university outreach program that Alyssa Tong is envisioning for the advocacy and outreach effort. So university students would probably benefit dramatically from knowing that, hey, here's this concept of code coverage. You probably already learned about it in some of your coursework. But if you haven't, here it is. And this is how you can visualize it in your Jenkins on your personal computer, on your very own computer. Run a Jenkins for one, yours, and get to get accustomed to it so you can do your coursework. See your code coverage, use it to diagnose your failures. Do continuous integration of your classroom assignments. Whether or not your instructor requires it, you'll benefit from it because it's just a better way to do software. Right. And that's because I, you know, busted myself. After writing that about how you need to do all this different testing, then the sample, the simple pipeline they start out with is build, test, deploy. Right. So we're not reinforcing that. And I, you know, it really should have several test stages to it, right? It's certainly, it's fun for me anyway to highlight, oh, hey, there's this, there's this. I'm not sure that that's a typical university experience. Build, test, deploy is already probably better than many of them will get for most of them to build. And if it works, you're done. Right. Yes. If it passed, yeah, I can remember. We used to like take junior people and they who do, and then we get them a code review with one of the really good people. And some of them would walk out and say, that's a total waste of time it builds. There's no compiler errors. You know, why do I have to worry about all this crap? Others would come out and say, I will take any assignment that lets me work more with this person. I want to know what he knows. And those are the people we kept obviously. But I mean, there's just little things that we could do to reinforce. We really mean this, you know, or to start to see the, you know, things like, well, that there may be when you deploy it to a staging, you might have separate tests that you would run on the staging server. Right. Or, you know, how do you, you know, do you build and then do you have six test stages in a row? Or, you know, just even a lot of it is little things. A lot of it is not a big piece. It's just remember what we say in one piece and reinforcing it in another. Well, and there are really cool additive stories, right? There's the, hey, we're going to do build test deploy. Build test deploy is great. That's really great. But now you may be in an environment where the test phase is becoming too long and you or you have production specific tests or staging specific tests. How do you do that? Well, what if I need to test webpages using Selenium? Okay, this is how you might do that. Or using Cyprus or one of the other page testing utilities. And what are the compromises you're making with that and how do they behave? All really cool ideas, yeah. Or, and another way we could go is rather than trying to do that sort of top downs humanity student approach would be we could pull out pipelines that we're using in Jenkins. They're all public. So we're not giving away any secrets, right? Right. And have a very avuncular commentary that goes down them about what's done there and why it's done. And you could instead do it this way but that would have the following drawbacks or even say a better way of doing this might be. Right. And that might be in terms of our audience that might be a better learning path if we could, if there was a way to make it. So it was very nice and readable. Right. So things like this where we say, hey, here's this thing. Yes, it's public. What do you know? It works. And this is how it feels. Or you had asked about plug-in adoption. So I had just adopted this one. Elastic access plug-in, I think. There we go. So here it is. I just adopted this one and here are its tests. All 84 of them, here are the artifacts it created. Built, here are the changes that came in. This one was a change from Daniel. And if we look at the poll requests, I mean, it's got quite a use, an interesting story, a simple story to tell that, hey, here's this thing. And this is the experience. Okay, wait a second. Where are the tests run? Where are the tests run? They're run on the Jenkins server. Is that what you're asking? No, I don't see a stage called testing. Oh, well. Are they part of the build stage? Yeah, so they're part of build. Is that a good practice? I have nothing wrong with it. If in this case, the way the Jenkins project thinks about it is the build phase is run Maven, clean, verify. And what Maven thinks about is when I run verify, I run all of the pieces of that preceded that step and that includes all the testing, everything. So this particular structure is well suited to Maven projects because the build thing just says verify and verify runs, for instance, the coverage report. And it runs- So the point is Maven's actually doing the testing. Correct, right, and that's quite typical. Okay, and that's something that doesn't show up any place in my world. Right, fair enough. Thank you, it will, it will. Right. You know I'm a little parasite. Well, and the concept of use your build tool is a really good concept, right? If your build tool already is running tests for developers, use it. Right, and if that's the case, you might not have a separate test stage. Correct, right, and even without a separate test stage, here are all the tests. And yes, in this case, they all passed. Yeah, so now this one does this pipeline definition still has a weakness in that it does not show some of the cool information that's already included here. It mentioned coverage and here's the coverage report but the pipeline definition or the blue ocean interface is not showing that coverage report. So the coverage report is here and it tells us, hey, we covered 65% of the conditionals and 66, 2 thirds of the statement of the lines and 2 thirds of the instructions. Okay. Yeah, and it's like we don't, I mean, we don't wanna take over teaching people how to do testing and yet, we wanna give them at least hints. Right, well, we want them to correctly perceive the significant value they can get by having a tool like Jenkins that will automate many of the steps that they would have done interactively. Right, right. And so, but it sounds like you're saying if you're using a build tool that their validation may be enough for you to satisfy your testing. Right, yeah. If you're not using a build tool, or what about if you're using an older build tool like make or ant? Especially make, there you're gonna have to do testing, right? Well, make is a good choice there. With make, we've got examples that we, where we use make in the Jenkins project actually, like the Docker images are built with make and those Docker images, let's see if we can find them. Using make to build the Docker image is actually quite effective. It works really well because we're not doing anything that's Java specific so Maven's not a great choice. And so using a Docker image or here, another example for you and me, Jenkins.io, the page generation or the creation of our website is done with make. All right. And so when we look at this thing in Blue Ocean, we'll see a clean, a checkout, a build, an archive. And in the build, what you'll see is make, make all. So make is very much very, very real for people who use now. Now in this case, make can be taught pretty easily to write output that is presentable in Jenkins tests. So it's not uncommon for things to run, have a make test and the output of that can then be used to present into the tests. Now, this website generator does not do that. Okay. So that you would, you know, evaluation is that we don't do adequate testing on that one. Or maybe adequate for what's needed. It's not as a model, it's not a model of testing but right, this one is if I were building some C code and I didn't have any tests running, I'd be worried, right? Because that's scary. If I'm compiling code to put into an embedded device or compiling code to include into a product I'm shipping, I want some tests that tell me that it's working. Right. I haven't gotten deep, I still don't know what I'm doing but Tammy and Ben Walding have got, when you build this stuff into Antora, there's the actual tests, doesn't build and stuff. And then they've got all these recommendations and they are testing for all sorts of stuff in the docs. That is right now it's sort of a pain in the butt, but like they're using sentence case for the titles. I think they test for that. Yeah. It's interesting if they get anything that looks like it should be an abbreviation but can't resolve. So you get, it doesn't stop, it doesn't break your build but it's doing a lot more documentation testing stuff. It's kind of interesting. And that is a class that I would call, that's a style of test, I'd call a static analysis test. So static analysis is commonly used for things like, well, in the Java world, static analysis is done, oops, wrong one, in the Java world, static analysis is done with things like spot bugs, where what it does is it will look at the generated bytecode and give hints, hey, there are this many warnings from spot bugs. So here, if I look at this one, it looks like it's not showing me the spot bugs output. So let me use a different Jenkins instance. But here, let's look at this one, where we see here, notice this one has check style warnings. Yes, here we go, check style Java, spot bugs warnings. And it tells me, hey, there are none in this build and it ran them and I could, okay, I work hard to keep no warnings here. Let's look at one that has a bunch of warnings and this lets me navigate with the warnings and G plug-in to see types of issues, categories of issues. So, hey, there are this many, there are 360 warnings in this thing related to Java doc. Okay, and I can explore those and go looking for them and very, very powerful way to make my code better. Okay, as you're talking about this and you could go on like this for another hour or two, couldn't you? I probably could, yeah. How do we capture that? I'm thinking for somebody, Jr., trying to get this, this is the approach, somebody who knows what they're doing, who just goes through all, I mean, do a little planning to know where you're looking and what you're gonna point out. But if somebody sat through this and had the background, when they came out of it, they'd be a much better pipeline developer, wouldn't they? They certainly could get much better capabilities, much better results from Jenkins if they knew, oh, here's this, and we've got hour-long videos recorded by the maintainer of this particular plug-in that talk about, hey, this is how you use it well. But that one plug-in, but the one that you're putting on, yeah, yours could have cross references to other things with more details. Right, exactly. Just to show the amount of stuff that's available, because I'm thinking, I mean, I could, if we could afford your resources, which you can't, but I could pull all this out and write it, but it wouldn't be as effective as what you're doing and all the screenshots and stuff, just you walking and talking and... Right, right, I mean, there's an, although I think there the danger is, and it probably highlights, we should reconsider something like Liam Newman's Pipeline Minute Videos, right, or Jenkins Minute Videos, where a two-minute summary of this, what's that? All of which were two minutes, but details. You are, your excessive precisionometer is going off-scale. Yes, Jenkins Minute Videos that in fact were two minutes and in those two minutes, people saw very rapidly a destination to which they could aspire and oh, this is possible and it's possible with these steps and then they go looking, how do I get there? And this is a good example of, wow, how do I add check-style checking to my project? How do I add other forms of checks, like coverage reporting? Okay, this one is one that I use because it helps me see what's, which statements are covered and which aren't. Right. And I can look at source code and say, oh, shame on me, here's a class with lots of, lots of content, but all these red lines are my reminders that I haven't called this, these statements, somehow or other in my automated test. So that would be a very good thing for somebody to have for code review, right? Right, this is, it's a good help, it really is. It's much more convenient to be able to say, hey, which statements have I missed? Maybe they're not important and I don't need to test them with automation. Right. But if I can test them with automation and they are important, it's good to know. Uh-huh. Yeah, so if somebody's reporting a bug, if something's not working, it tells me I can go quickly and look for things that are not being tested. Right, that there's certainly a hint when I get a bug report, if it's in a Java class that has zero code coverage, that may be a good excuse to go write some tests for that. Right. It's like, it's like so many things. Like I maintain for reading that the learning the ABCs and how the letters are put together in words is the hardest part of reading. Once you know that, then it's just a matter of building up your vocabulary and learning more and more words, right? So my elementary educator, professional wife may have disputes with you on that, but that's okay. I've learned not to wrestle with my wife about education theory and how it works. I don't claim to understand it. But let's take a step up from there. Figuring out that there are 30 different things that I might be looking for to test my code. And here's the tools that you can use to help. Here's what they mean. Even give me a number. I mean, if I'm testing 30% of my code, how confident am I that it's good? Right, right. 75, it's 70. I mean, obviously if it's 100% and they're good tests, if I'm used now, do I need to do code coverage if I'm building with Maven? And you can't trivial a do code coverage when building with Maven. I certainly do it all the time. And it's a value. It is very, it is intensely valuable. Okay, because Maven doesn't give you code coverage, right? Well, Maven allows me to do something that happens here quite naturally. This is a Maven build and we'll see the, let's see, is there a coverage statement here? There is not. So, but Maven is just a builder. It will run coverage tools and it does it very well. But you see, it's like all the details of each of these, if I know which one I want, in most cases going in the documentation is fairly decent. If I know that I want that, then I can go read the documentation and go for it. But getting this big picture is what must be incredibly difficult. Right, and that big picture is a software education, right? The big picture, certainly it's very valuable for us to share, hey, here's how you do code coverage. Why should you do code coverage? And what are the compromises that you're making if you choose to report coverage and care about it? Those are, I think, higher level concepts that we're particularly ready to dig too much into. Right, but we assume you know that, but then you, you know, you can kind of, we can pass off. You talk as if you assume that they know them, although you give them enough context that they'll. Right. So now, okay, dumb question. Is something like this, obviously you could do it, but you have other jobs. Is this a good project for Summer of Code or some of the other projects? Summer of Code, probably not because describing it season of docs, yes. Summer of Code is intensely focused on software development. Okay. So it's not a good fit for Summer of Code, but season of docs, yeah, it might be. Yeah, season of docs, yeah, or something. I don't know. Or even, I mean, I can almost envision a team project and it might even be for your SheCodes Africa, because I think they're working together closely and they are, they're not as interested in the strict content of the documentation, I suspect. Probably not, right? But for a group of them together to work and get this sort of put some glue on all the testing material. Yeah, not a bad idea. Cause as I say, you're sitting here and there's like, I didn't know that was there, but that's good. That's good, you know, if I knew to look there, if I don't even, I'm not positive, I know what CheckStyle is for, but if I knew I needed CheckStyle and I looked at that, it all starts to fall in place, okay? Cause what I think is that we have an awfully lot of facilities in Jenkins that are underutilized because people don't know about them. Right. And there's nothing that points them in that direction. So, you know. And again, with agents, I suspect that most people early on figure out one way to do agents and they do everything in their shop that way. You know, they never, I mean, I think, if you know, say you have a big shop with lots and lots of projects, you probably need different types of agents. You know, some you want static, some you want ephemeral. Right. You know, some you want to be Docker, maybe some you don't want, I don't know, maybe everything should be Docker. And then there's the Kubernetes wrinkle. I've certainly found great use for static agents. And we've found great use for container-based agents on ci.jankins.io and great use for Kubernetes-based agents on infer.ci and release.ci. So I know there are use cases for every type of agent we offer. Exactly. And there's no easy way for me to see, these are all my options. And at a high level, these are the pros and cons of each one. Mm-hmm. And I realized because Daniel Beck fed me that Kool-Aid, I always knew that there's a place of static agents, but I can't tell you how many times I'm warning people about the security risk of a static agent. Right. Because it could get tainted. But there's no place else that's saying what the advantage of. It's implied in a couple of places because if you keep rerunning the same pipeline on the same agent, you're going to pick up a lot of performance because it doesn't have to repel everything. Right. Yep. The caching impact can be quite positive. Yeah. Yeah. Even questions about, let's say I can run agents either on Docker on regular cards or Kubernetes. What kind of agent is better on each? What are the advantages of Kubernetes agents over Docker agents? Right. Yes. Well, and to take the counter, how do you overcome, how do you best tune for or overcome any limitations? Yes. Kubernetes agents and Docker agents bias towards being ephemeral, but Maven and Java builds really benefit highly from a local cache of dependencies. So, and those are interesting questions that, okay, I've got something that's ephemeral, but I really need a local cache of the dependencies so that I don't waste a bunch of time downloading from some remote location every time I need to refer to a dependency. Right. Now, the problem is how do you, because I'm thinking in general, we probably get somewhat junior people in these, hack of these coding programs. Right. And this is the sort of thing that requires the great guru with years of experience and wisdom. Right. And that's the thing I just described is a deeply advanced topic. So, yes, that one would be a poor choice for the contributon. That would be a very poor choice. Right. There would be hints that could be shoved in along the way, but again, it's got to come from a very senior person. Right. And where are we where it's really worth our while to make this that much better? Oh, yep. So, however, any of these, if you're thinking about it, any of these would make a great DevOps talk. Or maybe it's Jenkins minutes too. Maybe we need to revive those. Yeah. I don't know. So, Meg, I apologize. I've got to call an end here. Any other hot topics you need to go? Oh, no, we didn't look at the feedback. Yeah, that's okay. I'll take a look at that. I didn't mean to divert that. I didn't. I thought we were... Oh, no, no, there's nothing here. I'll show what the data looks like. The data is kind of cool. So we asked several questions. What was your overall impression with one being worst and five being best? And six of 10 gave us five. Four of 10 gave us four. So between the fours and the fives, we were well perceived. Great. Which thing was most attended by the people who responded? Was the opening session? Second place, the closing session. Okay, those are good. That says that they didn't join us and then not come back. Three of them weren't able to attend closing that attended opening, but then tracks, good involvement, and then key highlights. So which session was most valuable in this case? Opening session was most valuable. Closing session, second. Okay, that's good. But actually these numbers aren't useful because those are valuable to everybody and the others are smaller groups. Yeah, I'm okay with that, right? Yes, that's, I agreed the data. The things that I was most interested in was, hey, what about the feedback on future improvements? And that I'll summarize to get it ready for tomorrow's governance meeting. Okay, yeah. And we also, the survey, I wasn't sure, doesn't say, doesn't differentiate, doesn't give you a place to say, I didn't attend the session, but I watched it later. Oh, right. And that's true. And that's a good piece of data that I can actually gather is go look at the view counts on our session recordings because we've got that data in the YouTube account. That's a good one. I'll do that. Thank you for suggesting it. Because the contributor summit playlist has all of the videos in it, for instance, 170 views of the opening session, which is not bad. Whoa, and much more interesting than the, and we're not getting feedback from those people. Right. The 11 who showed up, yeah. Right, that's, well, there were 25 total who attended. We got 11 responses to the survey, but 170 views of the opening session is pretty good. So that's not a bad thing. You know, it's not as good as some of our other videos like the video that we've embedded on the Jenkins website on the top level page. That one is, has 17,000 views since December 11th, when we put up with it. So we clearly are not overachieving in terms of number of people who are watching our recordings of status sessions. Right, but it's also, you know, it's a smaller unit that are interested in the status too. That's a, right. So, cool. Okay, you were gonna go, go, go. That's, let's call it done. Thanks very much, Meg. Thank you. I learned so much every time I get on the phone with you. I love you. All right. We'll see you. Best of Colleen, bye.