 Welcome to the European Docs Office Hours here on June 30th, 2022. We have a little bit of an agenda today, going over a handful of different things, a couple of item updates from Mark regarding the Docs mailing list and a couple of blog posts that will eventually be given, shared in a week or two. We have the Jenkins LTS Change Log and Upgrade Guide that will be coming out soon with the next LTS release, which is going to be in a couple of weeks from upstake and mark. Ideally, of course, and then we have Vihan here. So if Vihan can give us an update about the Google Summer of Code, that would be great. And then some other items about the Java lever requirement and things that are happening right now that folks like Basil Crow are helping us out with and making sure that everything is ready to go for continuous improvements. And then if there is some time and we have the chance to, we can go over some further localization with Crowded. If Alex isn't here, we can pin that for next time. So Mark, if you want to just kick us off, talk about the first couple items here under the action items. Yeah. So no progress on archiving the Docs list and no progress on the three blog posts. They'll have to wait for at earliest next week. That's it. Sounds good. Yeah. And then the Jenkins 2.346.2 change log and upgrade guide is something that Mark and I are working on and will be working on as we go through. There was some discussion about potentially doing that today. We can definitely come back to that if that would be best mark. I did want to make sure everyone has a chance to share their updates and whatnot. So, okay. But yeah, that'll be taken care of and we'll be sure to update everyone when there's further news about that. So if you want to share updates on the Google Summer Code project and what you've managed to accomplish in the, since our last meeting. Yes, sure. So in the last meet, I was working on the data types of the steps, the parameters and bringing them up to the top. So that pull request is created and it is working fine for now. We are reviewing it for some possible refinements. So it is not yet merged, but I'm sure it will be that the result of that PR is pretty good. So for some larger pages, I observed that the page length could get reduced up to a seventh or a sixth. So that extra space that the types were taking or being shifted to the top are actually more readable also because earlier the user had to expand the parameter and then go through the help in order to read this type, but now it's there in the top itself. So yeah, that is working fine now. And today I also created a draft to request in the pipeline metadata utilize repository that is a repository we'll use to maintain the remote plug-in manager that is to be shifted from the pipeline step dogs repository. So our plan is to release it as an artifact. Release the metadata repository as an artifact on Maven, which can then be imported on to the pipeline step dogs repository and used basically as a dependency and then we can get rid of the classes which are there locally. So this will help the other projects which want to use the power of the plug-in manager without running a separate Jenkins instance without mocking it in their own repositories. So that is a process that we also want to take some help from the community because neither Christian or I have the permissions in order to push for the or the Jenkins group on Maven. So that is something that it will require some help from the community in the upcoming week. And yeah, I guess that's more or less of it. So yeah. And I saw that you had posted in the Gitter channel about a couple of above pull requests and everything. Was there anything that you'd like to demo or share here? I can stop sharing my screen if there's anything. Just want to make sure you give me that opportunity as well. Sure. So I can demonstrate the data type pull request if you'd like that. Yeah, why not? Let me go ahead and just run it real quick. So meanwhile, we also reviewed the plug-in list for requests and as per some feedback from Tim and Mark, I think it is best suited not to work further on that particular feature. We can leave it dangling as it is over there. And in the future, if you feel that we have some other idea regarding the same, we can perhaps create a new pull request or update the same towards it. So yeah, I guess that is more for that. So I'm not working anymore on that particular feature. So I'm just running the Jenkins right now. And what kind of things can we do as the community like for reviewing the pull requests and anything else that might be coming up? What can we do to help out in these cases? I think as of now, I have three pull requests that are being left to merge. Small one. So what is that plug-in list which I mentioned? So nothing to be done on that side. But on a more general note, I think whatever UI-based changes are there, I'll share on the box channel the screenshots and everything like I did for the data, I think. And for the more back-end kind of stuff, the release and all, I think we'll let it, we'll let you know on the channel itself. So if you require any help as such for the pull request and everything, I think everything is going as smooth as it can probably. Yeah. So I'll just share my screen real quick now. I guess this one's, so can you see the screen by playing Groovy Library, is this one? Yes. All right. So I'll just show you the main, the larger one so that you can get an idea. So what I did to see the page size was I disabled the JavaScript altogether. So all these things got expanded. But we can see from the flow itself. So these all are there on the top now. So you can see the data type right beside the name. And for larger things, such as this one, when you expand it earlier, the string was coming all under under this stuff. So we had to go through this stuff. And till the time you reach there, you actually forget what that type was really about. So that comes out of nowhere. So that space gets saved as well. And this is now coming everywhere. So I've handled every particular situation because there are a couple of different types of nestings going on over here. So all of them are taken care of now. And all in all, I think this feature is working fine with the pull request. So this was a little demonstration for the scene. Yeah. Thank you so much. That looks great. That navigation looks a lot cleaner and everything's very, very nicely placed in a line. So that's wonderful. Thank you so much for all this work and everything that you're doing for the Jenkins project. It's really appreciated. Cool. So now that we've gone through the Google server code, just a couple other points here. So with our weekly release last week, or was it this week? I forget now, Mark, which was it last week or this week? We released that push the Java level requirement this week, right? This week. Yeah. Okay. So with the weekly release line, the Java 11, Java 11 is required. And so alongside the Java 11 requirement, there are other improvements and enhancements and upgrades that need to be done. Stuff like jetty being upgraded from version nine to 10. There are some other API upgrades that might need to have that need to happen as well. Stuff like the serve late API specifically. And the encoding will be changing to UTF, eight instead of go to ASCII doc. So a lot more uniform and consistent across organizations. And Mark, is there anything else on the Java 11 improvements that we should be aware of or note here, or does that cover the general idea? I think that covers it. Thanks, Kevin. Yeah, no worries. Of course. Great. So that actually takes care of the agenda pretty quickly. Mark, did you, was there anything else you wanted to go over or take a look at here? So Veehan, Veehan had mentioned of something that I think is worth a question to him. So Veehan, you indicated you and Kristen may not have permissions. I think we gave Kristen permissions to the permissions she had previously that should have allowed her to release new versions, at least of pipeline step stock generator. Was that what you were referring to? Or is there something else? I was referring to the Maven deploy permissions. So basically under the groups that we have right now. So for example, what I plan, what I was planning to do was we can define Jenkins file for that metadata repository. And in that we will push to the Maven repository for that particular artifact every time the source code changes. So much like it happens with the other things also. So for that pushing the Maven repository, I think it requires some different permissions and I'm not sure how it is done. And probably if I'd get some idea of a similar repository and to see how things are happening. So maybe some other artifact to see how it is working out. Then I can maybe just take some stuff from the Jenkins file. And after that whole thing is released ready, then we can. Then we can ask about the permissions and all required to do the same. Okay, so it may be at least I think it's worth you exploring. I'm going to put a hyperlink into the document. And then going to ask Kevin to click the hyperlink so that we can look at it together. But I think you may want to try this. So what incrementals are is they provide a facility for Jenkins plugins to do. To save the results of pull request builds. So Bruno submits a pull request to improve the get plugin. And when he does that. His pull request actually becomes the binary of his pull request becomes visible for other people to consume. Through repose dot Jenkins.ci.org. And they then can refer to it by this, this incremental syntax. So this special version number that says this is an incremental. And this page talks about how to do that. You may want to explore that. I'm not sure if it will work with, with non plugin components, but I would expect it to work with them. So you may want to look at, could we enable incrementals on pipeline steps doc generator, for instance, if you need to do something with it. Ultimately, I think the thing you want incrementals on is probably the, the library or extracting right rather than the generator itself, but, but it's pipeline steps doc generator gives you a place to test drive that like. Sure. So we also saw some other non plugin repositories that had a release type of feature. So the first thing that we looked at was the plugin installation manager tool. So that had a GitHub actions and everything set up for it. So it had releases also, but the one thing that I couldn't find for it was a Maven artifact. So I don't think it is published as a Maven artifact on the repository. Basically I was looking at the Maven repository.com for all the repositories associated with Jenkins. I assume all of them are present on that link itself. Well, so let's your question is a good one. Let's take a look. I think I can show that the Maven that the plugin installation manager is in fact deploying to the repository. So let's are you okay if we explore that for just a little bit? Sure, sure. I would love that. Okay. So Kevin, I'm going to put another hyperlink into the document. And let's let's use this as our test case. So plugin installation manager. PR. Sample. And let's try it. So. So there's the Kevin, if you can click through that link. What that takes us to. Oh, nice dark theme. Well done. Okay. So. What that takes us to is. Here are components, including jar files with interesting version numbers inside there, the name of the file. Now if we copy that one of those file names. I'm going to try searching repo dot Jenkins CI.org to see if I can find that thing. I'm going to go to repo dot Jenkins repo dot Jenkins dash CI. dot org. Right. And you may not be able to search at Kevin because it may require authentication to do the search. Got it. But let me, I'm going to explore this to see it may also take more time than we've got to do. To find it, but if I look for that. Okay, let's try artifacts. Okay, and incrementals. And what is plug what is the path of the plugin installation manager tool. It is. IO dot Jenkins that plug in dash management. Okay. So, I owe that plugins. No, I don't. Jenkins plug in dash management. There it is. Okay, so I owe. Like in management CLI RC. Okay, what was our string that we were searching for again, it was something like embarrassing. It was an RC something or other. Here we go. So, the thing I'm looking for is 2.12.4 dash RC 621. 2.12.4. No, as I'm seeing an awful lot of. Yeah, here we go. I certainly see lots of them. Yeah, this one is not okay. So it looks like the plugin installation manager tool is definitely Kevin I'll send you a URL. Let's, let's get this one. So I'm going to paste into the document another URL that will let us navigate inside the repository stored in Artifactory. I'm going to paste this location. Okay, so try clicking that and see if it opens us into a, oh, it would help if I did a better job of copying and pasting wouldn't Mark, don't you share your screen. Sure. Yeah, I could certainly do that maybe much easier. I'm not sure that it'll help. We need a document that shows where we're at, but here let's share my screen just in case. Okay, so share screen is right here. Okay, so what you should see on screen is the Artifactory location. Am I sharing the correct screen. Yes. Okay, good. All right. So the place I am is I am in incrementals. .io dot Jenkins that plugin dash management plugin management CLI and now as we look through all these artifacts, we'll see a one dot 12. No, what was it? Is it 2.12.4. Here we go. 2.12.4 dash RC 618. This is the one that is corresponds to pull request 416 most recent build. So I think beyond this thing has facilities to do so plug in installation manager tool does deploy incremental builds. And I think that means you can should be able to do the same thing with plug in steps doc generator. So let's let's see if we may want to do a comparison between plug in steps doc generator and and plug in installation tool manager. I suspect what we'll find if everybody's okay with me again sharing my screen or continuing to share my screen here. Let's look at. Sorry for interrupting, but okay, we have seen that maybe the plug in could store the plug in artifacts in that are the factory or J for whatever the repository, but could anyone consume that afterwards or should the people who want to consume that have a login to this website to this repo. So the artifacts can be consumed without requiring any authentication. And so so as an example as an example that that I specifically use when I need to make a change to the get client plug in, I'll make the change in the get client plug in and then in the get plug in, I will reference that changed pull that the pull request incremental build that pull request and use it. Or when I need to test drive a an incremental plug in I will actually define it in my configuration as code. And it gets pulled as part of configuration as code. So so it's supported at multiple levels. Now let's see what what this thing. Ah, yes, there it is. Okay, good. So beyond here's the here's the evidence that this thing has been incremental has been made allowed to be done incremental dot mvn slash extensions. This thing is one of the components required for incremental builds. Now let's see if we can find a plug in steps doc generator pipeline steps doc generator right there it is. Okay, and it does not have a dot mvn directory. Okay, so what that tells me is plug in installation manager is able to deploy incremental builds. And the reason it can is because it's been incremental applied. I know that's not a word but it's been it's been given incremental capability. And the way that's been done is through this page, the instructions here on the Jenkins dot io page incrementals developing components in parallel. And what this tells us is to do this, we say incremental build. And we submit a poll request on the way to say, is this the right one? Oh, no. Let's look at this one. No, no, that should be it. That that was okay. Sorry, reading, reading more carefully here. So I think what we do is we run this command. And if I do that, again, everybody's okay with me doing this kind of live, live manipulation. Okay, so. If I do exactly that. First. Enable incrementals. Okay. No plugin found. Oh, now I think this may be Vihans question. Why doesn't this include the Jenkins parent palm. Vihan, didn't you ask that question earlier? Oh, yes, I did. I think you did. And it may be that in order to do an incremental with this thing, because if we look at the palm dot X and L file of this. And we compare it with, let's see what was it core plugin installation manager palm. Here the plugin installation manager has the Jenkins palm as a parent. This one has no parent. So, okay, Vihan, I'm going to just be as ignorant as I can and try this anyway. Nope, it still didn't like that. So there's more to it. So I don't know what all will be required. Mismatch. Oh, no. Okay, so there this does not this message is not unresolvable. I think it could be fixed because it's telling me something that it sees is wrong. And if I look at SCM, I may even see what's wrong. Yeah, for starters, this is wrong. So more research needed, but I think I think you might be able to use incremental on you may be able to use incrementals. If you're willing to do the investigation to understand this this piece. I think this helps me a lot actually. So maybe a one very nice type of question so earlier I was actually looking into the ambient repository dot com and I send the link on the chat actually. And I thought that was the artifact that was the place where we store all the groups and the artifacts, and I was trying to find most of them over there but then I also found out a repo dot. I think it's Jenkins hyphen CI so I found that so which one is a standard one like is there a difference between the two and what is there there is a difference between the two repo dot Jenkins CI dot org is the authoritative repository for Jenkins artifacts. So when when a plugin is released it's written to repo dot Jenkins CI dot org. When a palm file is released it's written to repo dot Jenkins CI dot org. It may be mirrored or copied to many other Maven repositories including the one you mentioned, but the authoritative location the original location where releases are pushed is repo dot Jenkins CI dot org. Oh, right. So basically we can take any artifact over there and we can put it in our formula dependency. Anything that is available on repo right should be able to yes. Now that's that's a pretty bold statement so I'm sure I could be proven wrong in many different ways but but repo is the authoritative Jenkins repository. Sure thing. Yeah that helped me a lot actually a lot of my doubts that we are that way. This is great actually thanks thanks a lot for doing this. Thanks. I look into this one. Okay, well and as a favor to me if you'd be kind enough to this one single change that I made needs to be made no matter what. So I'm going to show you this one. Sorry go ahead Bruno. Yes sorry that's because the grid protocol is not available anymore forget that that's it. That's correct. Exactly. So, so this URL is just broken. It won't work anymore at all. Now it's it's never used as far as I know so the fact that it's broken is hardly ever detected, but GitHub has turned off this protocol completely and they no longer even answer to that protocol. So in order to give them a URL that will answer you use this HTTPS instead. And I guess one more question that I would put here and is there a need to set up GitHub actions for the metadata users that will create. So for the plugin installation manager we have. We have the release system on GitHub itself. So do you think it will have any real use for the pipeline metadata is also. I think it would be quite useful and and there's actually documentation that describes how to do it here on it should be this one. No, sorry, not that one. Jeff dash 229. Jenkins release automation. Okay, we're going to have to go find it the hard way the search engine is not finding it the way I wanted developer guide. How to guides. Release. Setting up automated plugin release. So this, I think the same technique for automated, automated releases that's being done for, for other tools could be done for, for the pipeline steps documentation generator. Now the plugin installation manager tool isn't using those as isn't using this particular form of delivery. It's still released and is still released manually. But but the idea of automating release is a good one. And your question, should we be doing other things? Let's look at some of the actions that are on that repository just to see. So release draft or yes, if you don't have release draft on pipeline steps doc generator, you want it. It's a good thing to have and publish artifact. Isn't harmful. It's, it's a nice thing. What, what we get with publish artifact is when I look at the list of releases here. This list of assets includes the jar file. And that arrived there because of that GitHub action. So that GitHub action is smart enough to go find the place that builds this thing and copy it into GitHub for convenience. Now I don't know that pipeline steps doc generator will benefit much from that. But if we look at pipeline steps doc generator, let's go look at it. Pipeline steps of shame on me. It's not here. Okay, fine. Pipeline steps. Nope. Okay, just a minute. We'll go find it. Line steps. Is it in infra? Help me out here. Yes, it is. Ah, okay. Good. There we go. Okay. Okay. Right now this doesn't have any actions to find, but I don't know that for instance, it also defines no releases. And so the release drafter thing won't help much. Now you may, you and Kristen may together say, Hey, we should start using releases so that we have known points where we can declare this was what we delivered in this release. And if so, then release drafters are good help. The way we use GitHub actions for Jenkins repositories is just to document our changes as releases. And maybe to like we saw there, maybe to provide links of those jars as the releases come. So that that's it, right? So the repo is getting pushed to the repo and everything that is happening with a different way. So with the Jenkins files, Jenkins file, I guess, and the Jenkins files file for that uses the build again thing. So that is also something that's very interesting because it's not a plugin itself. So yeah, so there are certainly more ways we use GitHub actions. For instance, we use GitHub actions to do, to do plug in releases through continuous delivery. Let's choose this one schedule build plugin. So what you'll see here is releases, this set of releases are actually generated automatically. And I believe there is an action associated with that. So we're using on this one, we use GitHub actions to support our continuous delivery process. We also use GitHub actions to support translation into other languages through crowd in. We also use GitHub actions to do security scans. We also use GitHub actions to label pull requests automatically and those are all valid uses. So now I don't know if any of those, this one, the CD one may be quite helpful to you. And that's described on the Jenkins.io page here. This one talks about automated plugin release. This is really telling people how to do continuous delivery. And part of that is this, this GitHub action other parts are described here. So right. So it talks about you need to make a change in the repository permissions updater. You need to configure release drafter. You need to configure a GitHub action for the continuous delivery workflow. You need to configure dependabot. Those kinds of things. Right. Did VHUN, does that help you? Yeah, it helps a lot actually. Okay. The main idea is we can treat a non plugin repository as a plugin repository and use these steps over there. So is there anything that you have to prepare the repository before applying these changes? I love it when someone says something really bold. Yes. So what you, I would, I would rephrase your bold statement. You may be able to use many of these techniques on a non plugin component. And while you're doing that, you may discover things where you say, oh, this doesn't quite work and have to ask for help. And that's okay. Sure. Great. I think I took a lot of time, but it was definitely worth it for me. Excellent. Thanks for your questions. For me also, I learned a thousand things. Thank you Mark for taking time to explain everything. Thanks a lot Mark. Yeah, so, so Vian, you're okay then with the idea that if, if you want to do an automated release of, if you want to do releases of pipeline steps doc generator, and that's something to negotiate with Kristen, I think it makes sense if you want to do releases of pipeline steps doc generator, then. These, these steps, the enable release draft or enable incrementals, continuous delivery are all good choices. I think right now the way pipeline step stock generator is used is it's taking, I assume it's taking the most, it's either building itself every time it's used, or it's taking the most recent bill that I don't know which. So this is something that we can definitely look after our artifact, the artifact release thing is set up. This is the next big step for us. Great. Definitely something that I'll discuss with Kristen, the next project specific officer. All right. Super. Yes, but actually going to link. It was a schedule plugin for which we saw the different GitHub actions, right? The CD and everything. It was. And, and that's one of many there are 200, over 200 plugins right now that are enabled for continuous delivery. So schedule build plugin is just one example. Awesome. Yeah, that looks like we're all set for today. We are against time. So when we come to some given one of the time that so if Mark could stop the screen recording.