 Welcome, this is the September 1st edition of European Docs Office Hours for Jenkins. Today on our agenda, we have some action items, update on Google Summer of Code, some info about the Jenkins 2.361.1 release, and I think it comes along with that. We have some recently added blog posts about DevOps World 2022 in the Jenkins blog, which I wanted to point out. And then a couple of other topics from previous sessions, the search improvements on Jenkins.io and the commercial support page that's been proposed by Gavin. So just to start us off, Mark, would you like to give us an update on the action items? Yeah, so the archive, the docs mailing list, no progress, the blog posts, you can delete the Sheikot Africa Contributon, that one really is complete. Okay, great. That's it. Okay. Thank you so much. Next up, beyond, would you like to share what's been going on with Google Summer of Code? Mark mentioned you were talking about the Docs Generator and was able to add that. So yeah, just wanted to see what you had to share. Yes, so I was able to get the request for the pipeline search documentation generated on and we merged it a couple of days back, but it was breaking the site, it had some errors. And basically I fixed that by writing the code to generate the parameter folder. And even that was merged like a half an hour back. And Mark also created a pull request to test it on Jenkins.io, which I think has failed again because of that particular reason. So not able to debug what the error is, but it's not able to find that particular parameter file that I've created. So we'd have to debug it more, but I can show you the result on my local machine, like what it looks like and maybe we can look into it together if that's fine. Sure. Yeah, let me go ahead and stop sharing my screen behind and you can take over. Is it visible? Yeah. So I'll just run it locally first. And so basically the error, I think this is the builder that is facing and is seeing those as file directory, which basically should exist according to the local file that I have. And we'll be able to see that in a moment when the site runs. So I'm not sure whether this is happening because we've created a new folder inside the file structure of Jenkins.io, but you can maybe test it. Something else. So it is running. And if we go ahead and look into monitor branch, basically the loading time for this, this page required around 20 seconds before it becomes stable of the JavaScript going on. And the browser often requires only a couple of seconds now to get there. And for example, with the configuration I've added, many of these have been abstracted to the new pages. One of them is from SCM. And if you click on that, we'll see another list of all the SCM providers. And we can basically go ahead and check out some more configurations that we've done and in this something like this. So all these are connected within themselves. And if you want to, basically, it has given the error of the first ask it off that we had created. And if you can check the config, which was present that separated it, we can maybe find out the location and see if it is working correctly on the local machine. So. The clock will request, right? So let's see here. Yeah, so this is common for, OK, I think I can find it now. So, yeah, this one. So this is separated correctly as far as my knowledge. Yeah, this is working fine on my local machine. Not sure what is going wrong with the with the side generation. But any any thoughts on this one? I'm wondering if maybe it's not in the all ASCII that was just generated. Let's let's take a quick look at that. All right. So once that the the copy that I'm showing you right now is these entire docs are taken from the all ASCII or zip and unzipped over here. So these and that's the one that you downloaded from the most recent build. Right, right. From the request to one one. OK, so backlog. We can walk through the procedure again, I guess to double check. So but but what file were you expecting it to be in? Because I don't see a file in the copy of all ASCII dot zip that I downloaded called back low back. Anything more than just backlog dot a doc. Um, so when we unzip it, it will have a folder which is known as bad amps in it. And after that, so basically that for particular folder will consist of this file. Over here. Yeah, so backlog pull request SCM source dot a doc does exist in the copy that I see and it's and it's got some content. It's a K-byte. So yeah, OK, but you say that should be in params. Yeah, it is. OK, OK. So then so so what that means beyond is something something else is causing it not to be found. Is it not in the correct location or. OK, so it says no such file or directory content slash doc slash pipeline steps params backlog pull request SCM source. So is it possible that that is not being unpacked in that location? Um, basically earlier when the fetch external resource, as far as I can recall, it's it calls the OK, so it unzips it in the steps directory itself. And when we do that, the params will come within it. And if it's not able to find it, then I'm wondering how it is able to name this file correctly in the first place. So from where is this name coming? It's not able to find it in the first place because I've not linked it. It's not that the link is coming out to be like this. And basically, this is happening at compile time. So it won't even know if it exists or not. Is that particular link exists or not? That's been linked. That makes sense, I guess. So I'm not sure how it knows if this like the name of this particular ask it off in the first place if it's not able to locate it. So is the is the unzip that's being used, honoring directories? I'm not sure what script is used to. I use the standard Linux command on my machine, which basically gets the folder out as well. And like I can demonstrate that by moving to. Hmm. Yeah. And and it looks like so I can basically remove all the ask it off. So to be happy, I have these approach and it's sitting in this director, sir, and also remove the patterns folder. And if we do, OK, so this or ask it or ship is a new one. And when I do an insert, I should basically have a parent school sitting here. OK, so I'm exactly sure what's going on with the ask it off. Is it happening because we are creating a new folder, which indeed also requires a new URL location on the site? But is it flexible in that sense? I didn't think that that was the back to the message that it's it's displaying. Let's read that. It was saying no bundler, no fetch, external resources, no such file or directory. OK, so so it's that's external resources. OK, so the thing it's downloading is C I dot Jenkins that I owe job in for a job pipeline steps, doc generator job, master, last successful build artifact. I'll ask you that. And I download that same thing. Not sure what the other things are. Not sure what he's also starting from, but in the end, go ahead. The main or the folder that we want is the first answer. Not sure what the second or in the fourth line of the line. What what they are touching, basically. Yeah, and I think if we read that script, we should be able to see what it's what it's doing with resources, right? So tells Fetcher dot new process with recent resources and it looks like the the four arguments are the origin, the destination, the front matter and the zip destination. So origin, that URL destination, so it copies it into content underscore temp front matter, none required. And then zip destination, content doc pipeline steps that seems all quite reasonable. So let's see if I run it. Um, do you think that it is appending the name patterns over here? So not sure this has happened to me once as well, but basically giving so it's not able to find the end point of this. Maybe putting it like this, I don't think it would make a difference, though. But it's not able to find that particular ASCII doc and the URL mentioned over here is the correct one, the one we expect. Not sure why it is not finding it after mentioning the correct URL. Yeah, so it's now it does look like it's using Ruby to perform the unzip, right? And so if there's if the Ruby zip package does not honor directories, that could be a problem. But it seems like we would see that if we ran scripts slash external fetch external ourselves. OK, I'm running it now just to see. OK, and it says needs to load the package named Faraday. It's been a while since I did anything with Ruby. OK, Ruby, Jim package. I have same same error for me as well. Right, so it's I think what we want. What is Ruby gems? So we say gem space install install Faraday. Had a look a search within GitHub.com on this repo to see if it was called elsewhere. But unfortunately, there is just one occurrence in the make file and another one into Docker file. But that's all because I was wondering if you have the error if you have maybe somebody else should have it for other resources. But that's the only place where it is called. So false positive. All right, great, great. So now is there a way to install a gem as an individual user? I'll do the dangerous thing. And maybe it's stupid, but could it be just a transient and temporary FMR or whatever error if we relaunch the build? Would it fail the very same way? I would expect it to fail the same way just. But but it's it's cheap to try it. Let's do it because it can be running in parallel while we're investigating other things. So I've launched it PR5404 on Jenkins.io is the one that's evaluating it. And the same failure will be visible on the on the master branch. I could start that as well because then we've got two different places to check it. Yeah, good idea. So what command does it use to unzip Ruby? The one you mentioned right now that Ask your question again, behind. Yes, Ruby zip is the thing that's performing the unzip. I assume it would honor directories. I would be surprised if it did not. Now, is there a way we could check that? Actually, there is. I can probably go. Can I go to that pull request and look inside its workspace? I don't know if I can because it's a pipeline job. Workspaces, OK, so it's pending another. Well, let me try it locally on my computer. So behind the technique that you used locally that did work successfully for you was you did you modified something to allow make all to not download the file externally? Could it come again? How did you run? What steps did you take to run it locally? You downloaded all ASCII dot zip. And then what did you do? Then I commented on the fetch external resources part for this particular report. And I shifted all ASCII zip dot dot zip on the pipeline steps folder. And then I run unzip all ASCII dot zip. OK, so so the technique was comment out the all ASCII. Line 45 through 40 in fetch external resources. Got it. And then. Download. All ASCII dot zip and unpack it. Did you unpack it all the way into the content doc pipeline steps? Yes, that was OK. All right, so hang on just a minute while I do that then. Well, OK, I shall stop famous screen in case you want to. OK, great. OK. And the location where you unpacked it was content. Docs. Pipe doc pipeline steps. And I don't have a params file there right now. So if I say unzip, OK, now I have the params folder. And then you can run the make runs script for. Oh, you use make run. OK, I think that may be the magic I need you need. I believe you need to use make all. Yes, I tried that. So make all visit, but it doesn't run it. And then after make all, when it basically purchase everything and get something done, then I don't make run. So to test it, but basically make all was also running successfully because in this case, we've, anyways, committed out the fetch external resources part, right? So that couldn't be caught even if you use this method. And if we don't do not comment that out, we will get the older ones. But I think now if we since the latest in the repository is updated now, so last simple points towards the new documentation, we can try out the fetch external resources script itself. Right, we could could we could update fetch external resources to pull from the from the pull request or from the classes as well. Yes, well, and in fact, it's already doing that, isn't it? Oh, yes, it should. So maybe we can try commenting that out and removing all the ASCII doc that is sitting from that answer thing. So I try not to take much time. Make make all take some time because it's fetching a lot of resources through that time. Yeah, so so but because I'm sitting at. So if I if I take the if I do a make all from anywhere, it will fetch the external resources now. OK, so let's get that added. Yes, the same error as the pull request. OK, good, so go ahead, Veehan, excuse me. Right, exactly the same error line that you are seeing in the pull request. OK, as well, good. So you've got you've got at least enough information to do investigation. That you can check locally. Yes, basically, the fetch external resources itself is not working. So when the Ruby is fetching that and unzipping it locally, that is where the problem is. So we need to we need to investigate the Ruby part. The way it is. So while you're doing that, I'm going to go ahead and revert the the change to the pipeline steps doc generator so that we don't break the build of Jenkins.io site. Are you OK with that so you can do your investigation on a branch? I'm sure so I can do that. And I believe those changes would be needed in Jenkins.io and not pipeline steps of generators. So whenever we make those changes first in Jenkins.io, then we can re recreate that pull request from BSTG. I see. OK, so you're thinking is that the likely fix is no longer in pipeline steps doc generator. It will actually be on the Jenkins.io build process. Great. Great. Anything else to add behind Mark? Or is that does that take care of the Google Summer of Code update for the time? Oh, go ahead, behind. Nothing has to my say. Is it all right that if we move on in the agenda? So next thing that is on our agenda today is the Jenkins September LTS, which will be 2.361.1 along with the release, Faith has asked for a blog post about Jenkins for the Continuous Delivery Foundation blog. I'm working on that currently and have been able to get a lot of feedback and suggestions from the Jenkins team, developers, community at large. So I've been able to revamp and add a lot more information there. And I'll be sharing it as a pull request. And once I've actually submitted the pull request, I have to double check on what kind of formatting and file type they use. Since it does seem to be different from the regular Jenkins ASCII docs. So once that's been submitted, I will share it here and with the community as a whole. It's a high level blog post. It's not necessarily a technical document for the ins and outs of the Java 11 requirement, but more just to see milestones and a historical perspective of where Jenkins started and where it is to where it is now and where it's going. That is also going to include some information that I've been able to source from Basel's previous blog post about requiring Java 11. And with the amount of content that's going to be in the change log and upgrade guide, there should be more than enough information to go over and check out with the new LTS. The September LTS is going to require Java 11, as we mentioned. It's also going to bring support for Java 17 to it. So that's moving from preview to general access. So that will be another fun new update for users to try out. And the change log and upgrade guide itself is open for review at this point, we've got the backports and a lot of the other pieces added to it. We're just waiting on one or two other potential items. But for the most part, that's going to be ready to send out when the release is ready. One other thing I wanted to point out on Jenkins.io is the fact that with DevOps World 2022 approaching so soon, we have some contributors and other posts on the Jenkins community blog talking about their various topics and ideas that they're going to be bringing up at DevOps World. It's really exciting. This is back to in person for DevOps World, which is a nice return. And with everything that I'm aware of that's going to be happening, I wish I was going that much more now. But my team is going to be there. And I am so excited to see what everyone brings to the table and shares. The search improvements for Jenkins.io is essentially the search results right now are not as good as they could be. Some keywords don't show the results you would expect. But this is in part due to the fact that the Algolia search is older. Right now, we're using the legacy scraper. It needs to be updated to be more modern. And this will take some time to develop and figure out and configure. It looks to be something that's specific to the credentials that right now, Mark and Gavin Mogan are the two that have those credentials. So thankfully, Mark's already created a GitHub issue for tracking. But this will take some time to get going and get this straightened out. On the last topic that I have on the agenda is the commercial support page proposal, which was shared by Gavin in July. It's been a little bit since there's been any updates or discussion on it. So I just want to make sure that that's still visible. This is something that would greatly benefit not only Jenkins as a whole, but the user base and the community at large. The idea of having an updated support page would lend itself to getting that direct communication, be getting that easier support and even expanding the options of what support means, stuff like training, certifications, other commercial opportunities are all possible. And we want to make sure that this has the best set of information and support that we can provide for anyone that might be looking to use it. So if you have any ideas or want to get in on the discussion, that link is in the agenda and available on the community.jankins.io site. Was there any other topics that anyone wanted to add or go over here that we didn't mention or any other items they'd like to share? Yes, so basically one thing that I could think to rectify the error was in case we were not able to see why the unzipped thing is not working. What we can do is instead of keeping that params folder wasn't all ASCII.zip, we create another zip for it, maybe known as params.zip, and then we unzip it. And since that is a folder, it won't have any issues that we are facing now. And yeah, it should work. So that should be the green path maybe and figuring out why the folder is not getting extracted is the priority now. So maybe work on that. OK, thank you very much, Pihan. And I just wanted to say thank you for all of the continued work you're doing on the documentation. As a docs person myself, I really appreciate the fact of trying to simplify and, you know, could condense the bloat on these pages a lot. So I love it. Keep it up. This is amazing. So thank you so much for the continued innovation and contributing. And so OK then. OK, and with that mark, I think we can stop the recording. It will be available in 24 to 48 hours. Thank you. Was there anything else that you wanted to know? Yeah, so I was just listening on this. Pipeline generation. And I guess this problem with the subfolder is really just that we need to create the subfolders recursively. So there's like one line of ruby code missing because we're trying to write into a sub directory that wasn't created yet. So that should be fairly easy fix for. For the Jenkins I also behind, if you want to submit it, I've posted it in the chat, but the change that needs to be done. But yeah. Yes. And with the hope that there is only one folder missing because if you do that and it corrects the first error, then maybe you will have another subfolder which will have to be created and so on. I don't know. Yeah, so the code is already going recursively through all the files, but it's not. It's assuming that they're all in one directory. And so so it's been like the the perplexity for me is where would that change be applied in the fetch external resources? Yeah, exactly. So there's there's already this loop that goes through all the files. And I guess we just need to do this one and maybe add some imports. I'm not sure about that. Yeah. OK, maybe we would find the magic parameter set which would allow Ruby to unzip while creating necessary directories. Yeah, it's possible that there's some Ruby library that's like on a higher level than this simple zip API. Oh, oh, OK, all right. Yeah, so I think I'm understanding I hadn't looked at the code. It says if downloading a zip file extracted unzipping to and it does a maker of the zip destination, but then iterates exactly as you said over each file. Yes, exactly. And then online hundred twenty seven and just extracts into possibly non-existing directory. So we need this equivalent of the make their minus P to to create the folder safely. So we do want to create a request with this fixer. Should I take care of it? Um, it would be great if you can guess. OK, cool. It's possible. Mark, have you reported the full request already? Uh, I've I've submitted the pull request to revert it. So the pull request is being evaluated now. But it hasn't finished evaluation. So what we can what we can also do is for testing, just say that we want to download it not from the last master build, but from like fixed. So build number 800 or whatever was was the number where the pull request was applied and we can test it independently on the build of Jenkins IO because we probably don't want to block building the website. By by this. OK, so sorry to interrupt, so could you do another pull request maybe with your proposed fixed? And yes, my suggestion is to create a pull request that would pull a fixed version of the ASCIDOC, an old one, and it would contain this fix so that we can verify that it actually works. Yes. And then we have to rebuild the base. We revert the part that fixes the ASCIDOC, point it back to the last build of master and then we can independently merge the ASCIDOC generator pull request because this will only make the Jenkins IO part more robust. So it's not necessary to merge the Hans changes first. Yep, got it. I think even more that if you can submit your pull request relatively quickly, it will evaluate with exactly what's out on the system right now. And whereas the master branch is failing, your pull request, if successful, will then be able to fix the master branch when we merge it. So I'd say, Spinnock, let's have you do your first choices. Let's have you submit your pull request. Let's see if it fixes the master branch. If it does, then I can throw away my proposed revert of Vihans changes on Pipeline Steps doc generator, and we've got the solution then. OK, so that one's not the revert is not merged yet. It is not. That's correct. Then I will just do my proposed change and see if that helps. OK, cool. Right, and the folder part that we want to create, I'll just paste in the chat in case. So the one we have to pass the parameter and learn the name. And this is the file part that we want to create. Yeah, exactly. So if we add this Ruby code to make the unzipping recursive, then this folder should be created automatically. And it should also be future proof in case you add more subfolders in the future, then it should be no problem. Great. So the way I'm interpreting that, Spineck, if you're OK with it, let's give it, say, one or two hours. And if in the course of the next two hours, you successfully submit a pull request, we'll watch for it and merge it. If after two hours we haven't seen it, I'm going to assume that something got in your way. And then we'll revert the Pipeline Steps doc generator, and we can try again on another day. Would that be OK with you, Spineck? Yep, definitely. Great. It's not that the two hours is some magical deadline. I'm not trying to put pressure on you. It's rather that I want to be sure we have an expiration time so I don't leave the Jenkins.io build process broken for an extended period. OK. Great. Thank you. Thanks very much. Thanks for joining very much. And unless anyone has anything else they'd like to talk about, share or discuss, we think we might be able to stop the recording. And this time it will actually stop. It will be available.