 Welcome to documentation office hours. It's the 9th of August. Oh, oh, and Kristen, you're here. Excellent. Very good. Alright, so I had top of the list was a question from dirage on a poll request, and then weekly change log 306. And with that is the Docker images get additional tags. dash jdk suffix, then change log automation, LTS change log upcoming events. I don't have anything actually on that. So let's just call it Hectober fest. And that's those are the topics I have anything else that needs to go on the agenda before we start working through the topics. Okay, dirage first your question. What was the PR and what's the question. So I pasted the link to PR in our chat. Okay. Okay. So it's very basic doubt that I was embarrassed to even bring up then I said, Okay, let's do it. So in this we are writing. I added a demo, YAML configuration for this plugin called view job filters, and it's for, you know, anyone who's trying to understand how to write YAML so I've written and also when we are trying to write as we know we need to also write tests for the YAML configuration. So since I have not worked or written any tests before so I'm not sure how to do that. So here I've written some with the help of referring some other tests that were written previously in the repository. So as far as I could understand I wrote some things and now it's failing and trying to understand how to write ideal. Okay, alright so so well so let's okay so your question was, and just to be sure I'm understanding it is your question about the Java code here that is is executing the test, or is it about the YAML that you wrote there. I assume. Yes. Okay. Alright, good. Okay, very good. Alright so what we've got is you've added in the view job filters folder. And then there's a feed me that shows an example, and then you have written an integration test that tries to configure a view job filter, and ah, ah, right. Okay, and so what, what Tim is saying is that your, your test is, your test is certainly necessary but I want to be sure the constructor works, and what you're what you're testing here is you're testing that do the constructor, and then. Oh, right. But then, okay. So, so what's happening here I think anyway, maybe Kristen I should be quiet and let you explain it because have you worked on this particular code already Kristen. No, so I'm kind of learning here as well. Okay, so then, then I'm going to I'm going to just make my best guess and Kristen can correct me. I suspect what this is this annotation configured with read me says that the Jenkins that is started as part of this Jenkins configured with read me rule. So what Jay gives us is access to a what looks like a Jenkins instance, and that looks like a Jenkins instance has been configured by reading the contents of this, this job filter of this read me file. If it acts like this was the YAML. I would guess you actually want. I'm a little surprised it works like that because I would, well, I don't know what the rules are and how it does how it reads the read me but I assume it must look inside the read me and find a YAML block, and use the contents of that YAML block. But then what Tim saying is, okay, what this did is this configured a Jenkins instance that has views that contain a list, and the columns in the list includes status whether job name etc. What configuration happened but in your test. What this thing does this new build duration filter is it calls a constructor and creates a new one of these it is not looking at the Jenkins that is configured with this Jay thing here, and it's not exploring it to see that the values were set as expected here. I'm getting out of this too. Absolutely. Yeah okay so so what we need and but I think we can find exactly something like, like he is referencing here by by looking at other usages of Jenkins configured with read me rule. So, dear us if we look here, and I'm going to be lazy and switch to my text editor because I don't search as well with GitHub as I do with the text editor. And we need that file so whoops not that one. Sorry, we need this one. And let's duplicate that so that I can go grab it. I want to clone this plug in. So, dear us did did what I've said to this point make any sense at all or do you already have questions that you'd like to ask. Okay, alright then let's grab this thing because that is probably the best source of. Okay good so any one of these things will probably have a. Yeah, here we go. Okay. So what Tim said was we need something like this final Jenkins Jenkins equals Jenkins dot get where the. No, no, that's not. Oh yes there it is. Rule chain it's doing. I'm not familiar with chain rules so I'm going to have to go looking for a different example. And I could learn it, but okay here's one. This one is a public this J right and it says, and now somewhere in here, I'll bet there is a J dot. No. Okay, we keep looking to Raj. I can find different ways to write this. Right. Yeah, a lot of times sometimes these things try to find an example of another test where this where something has already been done and then just kind of see what they're doing. Here we go. Okay. So, so this one has a J dot get instance. So what that does J dot get instance returns me a Jenkins object. And from the Jenkins object now I can go to the Jenkins Java doc. So if I go to Jenkins Java doc so the Java doc for core and I look at Jenkins core. And now if we look for the, and this is a very popular word so Jenkins, the Jenkins object, just going to have to search for it the hard way. So here we go. This thing. Now on this. So here is the Java doc for the Jenkins object. And this was Tim suggestion, you could either return to get a collection of that is the list of all views or if you've got a specific view name. You can call get view by, by name, and then assert that the view that was returned has the configuration values you expect. So, does, does that does that help does that give you the guidance you were looking for. Of course, better than before, but I'm still problem to reach from Jenkins instance to my job filter specific tags in YAML. Oh, okay, so let's, but let's let's do some are if you're okay with it. Are you okay if we just do some exploring together. Oh, I would love it. Okay, so, so first let's list the PRs. Okay, so PR checkout. And 1603 so we're going to check out your full request. Okay, so now I need to see what's different between your pull request and master okay good here it is. So we need this file. And while it's running tests, let's open that file. Okay, so, and so what what we've created here, what you've created in your read me, where is the read me it is in a different location isn't it. There it is. Yeah, so this, this is the file right. Yes. Okay. So what if we just for fun took Tim suggestion and said, collection of. Okay, going back to Java doc now collection of view. Views equals J dot get instance dot get views. I'll bet now I have to import. And this is where it would be much better if I had an ID how sad. Okay, a view is a Hudson dot model dot view. All right, so now back to our compile step, and it's still downloading Wow. Okay, so it's going to take its, its own time. Wow, said, did not approve writing it that way. Interesting it skipped all the tests. Oh yeah what it's I think what it's telling me is that my attempt to run just one test. Yeah, I'm doing syntax. Okay, this is this is a multimodal project and I was unwise and said, oh, just do what I want. It's all good sometimes it's me. Yeah, it's like trying to remember something or like, Oh, I'll take it go faster and it's like, oh no. Right. Process everything. Yep. And it may be that this won't work either. So, so dear what the idea was is take Tim suggestion, and now he said, grab the view and what you are looking yeah, because the thing that you've got is you've got the views and you're looking for a list of views and then in that I assume we will want to look at job filters so let's look on Hudson model view to see if there is a way to get filters on it filter. I don't see anything obvious here. Okay filter. Okay. All right so is there some data here that is tracking. Maybe on the describable of the view that it might have the filters attached no, we've got a view. I'm not seeing it. Okay, let's go back to the, to the oops frames. Let's take a look for filter, because what I would expect to find is something that allows us to filter based on criteria like is a job running or not. Did it pass. Did it was it unstable, did it fail filter, maybe filter status filter. Okay, there we go. So this I suspect is the thing we need to find is the view job filter. And now how do view job filters get attached job filter that will filter based jobs based on its status. Yeah. So does this tell me. So what we want is we need to find this may be the place where it's best to get a debugger and actually watch it run because then we could explore the data structures. Let's see what we've got here. Okay, so it says, I use three class from Hudson dot views dot package so build duration filter build status and security filter. The three classes are the same ones which are used in Miami. Okay, and if we, if we look for those in the Java doc, I would expect. Okay, so that's not in core. So Hudson dot views dot build duration filter. Interesting. So you're saying it is in Hudson dot views. Interesting. Okay, well, so let's go look, I don't know if. So we should have said, oh, right, right. All classes. No, I have a suspicion is being proved. No, there it is Hudson dot views. And I think what this is telling us is that must be provided by a plugin, which it is Java doc. Job filters plugin provides this. Okay, good, which I guess you, you would have already told me wouldn't you because guess what that's this, what it says this plugin exactly as you documented it. Sorry, I, if I would read things would go better. But now the challenge is how do we get that from the top level Jenkins right isn't that what you're what you're trying to do is your challenge is you need to you want to assert that the values you assign like this amount of 60 and the amount type string of days are exactly are set to those exact values but in order to do that you need to find the build duration filter inside the Jenkins where it was allocated. Exactly. Yes. Yeah, and so now the challenge is how do we get it and I think I may have to go do some exploring with the debugger separately derage I apologize that I don't have an answer immediately because I think what we do is we, we would start from the views here and looking at each view. Let's see this has to. Yeah, we would look at the views and then on each view I would expect to be able to find filters associated with that view. Right. So, I think you should take your time then because we don't want to take up much time here. And my apologies this this is a this is a great one. I think I think we can go through and and do some searching there and and what I may do then is in our next session next week. I'll bring the summary of the searching if you don't mind waiting that long, or I could, I could send a send a textual summary as well oh hey here's how you do it. But the how did I find it is I think the more interesting thing because the, how do you find answers to these kind of questions is the is the better challenge right it's right the answer to the specific question is that is helpful, but not nearly as interesting is how do you answer these kind of questions in general. So I'm totally fine with the next meeting as well. Okay, great. Well, so let's let's hold put that there then and two small question on this I just asked very quickly. First one is, is this something trivial because I felt really bad for not being able to write this for this. So I think I think what you did was great. And, and I mean I'm delighted you thought to write tests and I'm really pleased that that they have a framework already in place that will allow you to write tests. For me that's that's quite impressive right it's this little thing right here is a dramatic step. It's a very nice step forward that they made. Hey, here's this tool that makes it relatively straightforward for you to write tests. Actually, I've got to I've got to look at this we've got to. Is there anywhere else. This is this looks brand new. I've never seen those before. That's really cool. Yeah, use the read me as a documentation. Well, and, and now the. Is there anything in there that would be that's already associated with view and it looks like that's yours is the only one yours is the very first. Oh no no view job is, is that the one. Yeah, that's the one you just added. Okay, so how about what if we tried filter. Now about what's another top level thing on Jenkins that we might have to iterate over the views. If I look at how about executors. Nope. Okay, so my, my dream of finding the easy, easy way out did not work. The second question was that this process of writing tests for jcat repository using Jenkins configured with the rule and everything is this. So, what if we write a blog on this to help anyone so does the, is this required or it's going to help like two or three people. That's what I'm trying to know. And I think it, I think it is worth the effort. And it might be, it might be a, and a cool way to introduce the concept of. So for instance, I believe we've got on the on the site, I think there is an introduction to Jenkins rule that you would be doing everyone a favor. If you're willing to blog more about it. So here's here's one mention of Jenkins rule. Jenkins rule for Jenkins unit tests. Here's the Jenkins test harness description. Notice this big blurb at the top. This is a work in progress and here is about the total of it. Configuration round trip testing environment variables so absolutely. This would be a great place to put, or a blog post would be just as just as good or a pull request into the configuration is code documentation. Sure. So this, this is exactly what my aim is because I had some trouble writing test here so I don't want anyone else to go through that that's why I was thinking over this. Right well and I think that's, that's, that's a great thing so. Oh, and here and now okay now this is now here is the terrible embarrassment. I spent 10 or more hours, when I should have read this section of the documentation. I just recently burned a bunch of hours, trying to figure out a solution to this class of problems sorry unrelated to your problem but a reminder. Oh, look at the documentation first. No, but it looks it's good that we have this. I'm so glad we have it. Oh, yes, yes, absolutely. Yeah, where I'm looking for something in the pipeline documentation and it's doesn't exactly jump out. It's maybe there but it might be harder to find. So I don't know if that's something that a lot of our users run into as well like where it's not, maybe not obvious. Right, searching and realizing Oh, whoops. Here's, yeah, here are these things. I've now used the shade plugin and I'm a little more familiar with it than I was before but shame on me for having, having learned at the hard way instead of reading documentation. All right so dear is excellent question let's put that as an action for next week. Mark, next week, summarize how to explore the Jenkins instance from inside a debugger running a test. And I confess. Oh, actually, maybe this would okay. Maybe what we ought to do is a dueling dueling debuggers exercise because Kristen, I'll bet you're an IntelliJ user aren't she. I use visual studio code. Oh, even better. Okay, even better. Okay, even better. So, so what we could do is is we do it as two steps as. Mark show, here's how I do it with net beans because it's the debugger I'm familiar with. And then we asked Kristen okay Kristen, can you do the same thing with visual studio code or did you do something different because dirage. I bet you use the s code don't you. Yes. Yes. Okay, so me showing with net beans maybe interesting in a strange and bizarre sort of way but not actually interesting getting things done. Okay. So, so Kristen, would you be willing Kristen we do a paired paired session. I'll show, show my exploration in net beans, you then do the same thing and say oh here's how you do that with the s code because me trying to show it in visual studio code will look completely non believable because I don't know how to use visual studio code. Sure, yeah, we can try that. Okay, good. All right. Cool. Okay, so we'll have some fun next week. That sounds good. All right, excellent. So dirage anything else on that question that we can answer. No, nothing is up now. Okay, next topic was the 2.306 weekly change log. I don't know if you've I you said you just awakened so I assumed you're as you haven't haven't done it yet. Are you still planning to do it, or should I plan on creating it. I always wake up early enough to start working on this. So I've already worked on it, and I have a question that's right in some minute. So I posted a full request link on our chat. So I'm trying to understand what should be the tag for whether it should be internal or not. Yes, that's a great choice. Look at that internal not applicable. Which is it, is it internal or is it not applicable. So, okay, I'm open to other people's judgment. I'm prone to think there is nothing a user of Jenkins is going to get from a change log entry for this. So my proposal is to stew the following. I propose to change this so it says that the rest of you think because this doesn't seem like something that they're with standard. I mean, this is internal stuff. Yeah, this is internal be below the you know below developer level kind of right to my mind right this is so internal. Yeah, so I'm, I think, I think I'm going to declare it skip change log. Okay, so it should go into the comments right. Oh, got it. That answers my question. Okay, good. Right. And I have not looked at the change log in a while so and so adjusted. I just a label on a pull request to market. Skip change log. Daniel and others make me find they disagree with this if so they'll tell us. Also, whenever we're writing an entry in the comments do we need to still apply that rule that it should be in the present tense something like that. Oh, that you know I, I hardly I don't remember the last time I reworded a comment. I reworded a comment that's that's in the YAML file as a comment, just because if it's in the YAML file as a comment. Usually somebody would want that comment to be able to take them to do the thing, leaving it as whatever text they did is fine, because it won't ever be displayed to a reader. Exactly. Okay. Okay. Yes. Right. Now we've got, we've got one change coming tomorrow that really doesn't go in the change log. But I'm going to use it for a blog post. Actually, I wonder, do you want to be a co author on the blog post with me. So, so what's happened is we've got, we've got the JDK 11. The transition from Java 8 to Java 11. Oops, Java 11. As the default JDK Java on our Docker images. And what that's going to do is that means beginning with 2.307 next week, not this week, next week. The Docker images will run under Java 11 rather than Java 8 by default. In order to retain compatibility retain the ability to revert to Java 8 by creating, we will retain the ability to revert to Java 8 by creating JDK 8 tags for the Docker images. As an example today. Jenkins slash Jenkins colon latest runs a Java 8 version of weekly soon Jenkins slash Jenkins actually tomorrow. Jenkins slash Jenkins colon latest dash JDK 8 runs Java 8. The next week. Jenkins slash Jenkins colon latest runs Java 11. So the idea is that we will give them this an escape hatch if they say well I cannot have you switch me to Java 11, I must run Java 8 then they will have to switch. Instead of running Jenkins Jenkins colon latest they'll run it with dash JDK. So if you're interested in being involved in that transition to your age I would be happy to have you be one of the reviewers of the poll request and we can talk about it and maybe test it together even see hey does it work the way or does it work the way we expect etc. Sure, I would love to do that but I'm not. I don't have much knowledge on this, but I would love to help. Okay, great. I would need guidance from you for sure. Yeah, well and and and just having someone to discuss it with and review it with would be a big help for me. That's great. I'll definitely join. Okay, great. So nothing that we need to say in the changelog for this one, but we'll do a blog post. And the idea is before next Tuesday's release describing this edition of the JDK suffix. And how will we be communicating wire IRC or get her. Good question. Yeah, so Mark and dirage. If getter works for you that'd be great by getter in the would actually would you prefer getter or do you want the Jenkins community channel getter is easy for me community Jenkins that I always just fine too. Let's go with getter then. Okay, great. Yeah, so we'll use and what I'll do is I'll plan to use the docs, the docs, getter channel. Okay, good. Thank you. All right, so I think we've covered 2.306 weekly changelog anything else there before we go to the next. Okay, next topic that was changelog automation, and we had talked last week that last week or two weeks ago that one of Daniel Beck's concerns was hey if we have this automation and no one reviews it it makes things much worse than the changelogs we have now. And dirage, you and I and Kristen and Meg as well I think I'll agree. Let's go ahead with the automation and we'll regularly review those pull request pull request so that we don't go make it worse. Sure. Is this something we can even do during at the end of the meeting can be just. Yes, absolutely. I think I think we could during during office hours it would be much more effective if we did it that way. I don't know if any of us forget. Right. Well, and it helps us all develop develop a practical vocabulary common vocabulary remind each other of the rules. Yeah, I like that. Okay, so I've still got to review review the pull request and approve. But I think we agree that's a good, a good thing to do and we'll, we'll enjoy it together. Next, next topic then was 2.2 302.1 LTS changelog the release candidate build is scheduled for Wednesday. And it looks like there's been no, no backports requested so far. So I've been testing 2.302 weekly for the last week and had no issues with it. So this looks like it will be a relative now. The changelog creation is hard work and I apologize. I think we had set our goal that we would work at this week and I'm not prepped for it. We could start it if you'd like in the we've got about 10 minutes left that we could we could spend on this or we could spend the time talking hecktoberfest, which which would be more valuable for you dirage and Kristen your, your, your take. I'm not sure which one to pick. I think change log would be better. What do you think Kristen. Sure, I think it's more pressing but I, is there anything that we just as a quick, is there anything fast quick we need to discuss for hecktoberfest or there isn't it's more about long term planning. So there really isn't. Right, good observation it's, it's much the changelog is much more pressing. And then maybe we can make sure we talk about hecktoberfest like first thing next time. Right. Like before, we can do that we can do our demos, but just that way of like if we need to do anything because it is good to plan ahead it's never good to rush but good, good point very good. Okay, so let's let's look at we'll we'll give ourselves up to 10 minutes to look at the 2.3.302 changelog. So first step for me is always to go remind myself of the generation steps. So Jenkins GitHub. And if I remember correctly we need the core Jenkins. Change log generator there it is. Okay, and this thing. Okay, tells us how to generate an LTS changelog for the back ported issues. But there aren't any back ported issues as far as I know, because if we look in Jira. I see and I have to put this off screen because sometimes Jira shows security sensitive things. So forgive my not showing it to you while I look to find it. Okay, next is we want to see issues that are LTS candidates. Okay, so here are three things that are LTS can't oh okay so they're, they're probably will be some back ports then. Interesting. Okay, so, so I think I've been just now proven wrong. If we look at core. Is there a backports pull request. I don't see a backports pull request. Okay, so I don't see it yet. But there are three issues here that are identified as backport candidates. Okay, so this one's going to take some a little bit of research actually to be sure that has the backporting pull request been issued. Okay, sorry so now I've got to go I've got to go look it up and see Jenkins release checklist LTS release checklist. And it is LTS 2.302.1 backport. Okay, so the backports are not yet complete. Okay, so what's what you're seeing on your screen is this is the LTS 2.302.1 checklist maintained by the release lead and the release lead this time is basal crow. So basal is basal has checked off the items that are done. But we've. I haven't seen a backporting announcement email, and I definitely have not seen the backports. So, so there's there's more work to be done before Wednesday's release candidate is available. All right, so that tells us that and and given that if I look here this this pattern to dot. What, what not. Let's look in Jira. Where was my Jira. Okay, so Jira 2.302.1 dash fixed. Two bugs labeled 2.302.1. Right, I'm completely perplexed. Okay, now I've got to I've got to go find this now I'm, I'm forgive my my not being able to navigate. Whoops, let's get download. So if we look at the change log for 2.289.1 changes since 2.289. So these are the backports. For instance, 65605. And it's this listed as 2.289 dash 50.1 dash fixed so there it is. There's proof that there are bugs that are labeled 2.289.1 dash fixed. So what they're saying is we should check for this and there are none labeled 302.1, and they're so okay. So the answer for right now is, we don't have anything that would be matched to this tool. So running that tool won't help us. The next process then is to look at the historical change logs and decide which of them should be brought in to the 2.302.1 since. So let's look here, we look at the weekly change logs and the ideas we're looking for things that have changed between 2.289 here and 2.302. What I've used in the past is I'll just do this. I copy the weekly change log into the LTS change log, and then start filtering things out by deleting. So it's usually this, this and this case. The left is the LTS change log, and we're going to do 2.302.1. So we'll steal the original code the original things here, and it will be 2.302.1 LTS predecessor is 2.289.3 LTS baseline. Now wait a second. Yeah, okay LTS baseline is LTS baseline is 2.302. Right, so compared to LTS baseline. Yes, okay. So this is so the changes section here would be anything that's backported. And then after changes there will be another section, which is LTS changes. And it goes here compared to 2.289.3. And this is the part notice that phrase selected by personal review. So currently no changes because the backporting PR is not complete. So if we look at LTS changes, what we want to do is, whoops, we want to compare. And so I start with 2.282.90. And I just copy. Now if we if it was a comment before. I'm reasonably confident that we won't care about it here so I leave the comments out. And you could either do it like this just copying and then deleting, or you could selectively copy. It's what it is is now it's time to think about it and say, okay, should the jetty change be included. And my answer is, yes, absolutely. And this one would be included. Should an issue archiving files greater than four gigabytes be included. Comments. Leave it for now we'll see. And should this one be included yes this is telling people they must use modern plugins. I would take that one out. And so the process you're seeing me do is, is the thing that I would go through, I will continue doing is going through it, taking each of these out and pasting them over here and then have to format them correctly so that they fit. Any questions so far. Which one do you pick out from the weekly to the, this one left one. So I pick things between the LTS predecessor. 2.89 289.3 or 2.289 and the LTS baseline. So, is that what you're asking dirage. Yes, yes. So let's start with 2.289 the predecessor, because changes will be visible to users for the first time if they arrived on 2.289 and we're not back ported to 289.3. So there's there's a complication that you have to we have to look to see for each of these was this one back ported to 2.289. And if it was then we remove it. And there's a good example. We just hit one right there. This first one that I selected was back ported into 2.289.2. So there is no point in mentioning it again because it's not new to the users and 5435 was also back ported. So it's not new to the users. This one is new to the users. So that that exercise is a very useful exercise. All right, we're now past that one hour time thanks for your patience. Anything else before we close down for today. Just a small question. What we were doing is from the predecessor till the current one we are fetching all the entries from the wiki automation file and pasting to the left one that he was showing. And then we were trying to find out that are these entries were mentioned in the previous LTS logs or not and if they were we are deleting them. Right. Correct. Yep, got it. That was my question. That's it. Yeah, excellent. You understood perfectly. Very good. All right, thanks everybody. I'll post the recording probably tomorrow the next day I'm a little bit behind on getting all my recordings posted. Awesome. Thank you, Mark. Thanks everybody. Have a great day. You too.