 Hello. Welcome to Jenkins Docs Office Hours. Today is April 4th, and this is the EU-US edition. Today we have myself, Kevin Martins, Bruno Vrachton, Akash Mishra, and Mark Waite, who will likely be joining us as we go. Anyone else who comes in, we'll welcome them as always, and join in the community. For the agenda today, I've got the next LTS release for April 17th, the latest weekly release. I know the blog post from Chris Stern regarding GSoc status in the application period. Some updates for the contributor spotlight. Quick note on the Jenkins Community Awards. Some notes on Google Summer of Code and where things are at. There were some updates for the Version Docs Project last week in Asia Docs Office Hours, so we'll discuss that a little bit further here today. There is mention of a demo in there, but that depends on whether or not Chris or Bandit shows up. If they do, we'll see from there, but we won't rest on that one. Just an update on Docker Compose in the documentation and tutorials. And then two new topics for discussion. The idea of a technical review or technical validation for pull requests coming into Jenkins.io. And documenting pipeline libraries with markdown or plaintext or HTML. And so the last topic is Mark's. So we'll make sure to discuss that with him. The technical review one is something that I put on there so I can speak to that fully in that sense. Is there any other topics that we'd like to have on the agenda for today, or does that cover everything that everyone had on mind about? Okay, and welcome Mark. Thanks for joining. Just finished going over the agenda and pointing out some of the new topics. Is there anything else that you'd like to have on here? We did. I did make sure to mention the documenting pipeline libraries topic here, but anything else that needs to be on there, Mark? Okay, cool. So starting off, so our next LTS release is going to be April 17, 2024, and that'll be LTS 2.440.3. I've created the change log and I've created a guide pull request so that can be viewed and reviewed here. Thanks to anyone and everyone that takes the time to do so. And just for the record, so the backporting ticket has been created. However, the release candidate isn't ready just yet. And the backport PR has not been fully approved and merged as of yet. There was one entry that was postponed on the backporting PR. So I actually just submitted a commit to my pull request to reflect that aspect of it. The other five are still valid in the fixed category. So those are remaining and I will put this one back if that ends up making it into the LTS. And then we also had the weekly 2.452 built and delivered successfully this past this week. And it's actually the current front runner for next LTS baseline selection. And it's actually been discussed in the developer mailing list already. Mark started this discussion earlier this week. And I'm sure you guys and Bezel pro have also said plus one for them. So things are looking up and based on the change blog and the community reports, there hadn't been any. So everything was really, really good for the last handful of releases. This one just happens to include a few things that we want to make sure are part of the next LTS. So, yeah, if you have any concerns questions or thoughts on that please add to the discussion in the developer mailing list. And if you're not part of the developer mailing list, you can always get on that via the Jenkins website and there's ways to get in contact. Next up. So Chris Stern submitted a blog post just to go over and cover the GSOC application period closing. So that closed on April 2. And Chris submitted a pull request for a blog post just going over where we're at with that what things we're looking for what the process has been like and where we're looking to go next. Bruno and John Mark Mason have already reviewed that provided some feedback. I still need to go through and review it. A lot of those suggestions that I would have probably made have already been made so I'm going to do a real nice deep dive on that and make sure everything else looks good. But thanks to Chris Stern for their constant work on this for their leadership on the GSOC partnership and everything else. Next, after that we have the Contributor Spotlight. So Bruno had his spotlight published last week. And then Erwe LaMira is going to be the next featured contributor on the spotlight. So his pull request has been submitted. Just looking to have him review that at this point Bruno's reviewed it as well. And a couple other folks have done their review on that for me so that's great. And once we publish Erwe, Mark Wade will be next up after that. And then we'll finish off from there for the time being and then we still have to look at the top contributors and see who else may be able to reach out for further spotlighting. Some folks have stepped away or just declined to be part of that process and that's more than okay that's their prerogative so we're respecting that. But if anyone does want to share their story and have that spotlight shown on them we want to make sure that we're part of that and having those conversations. And so I'll partner up with Alyssa and John Mark to see what kind of data we have and who we can reach out to on that. For the Jenkins Community Awards that voting period has concluded. Everything's done now with the CDF awards for Jenkins and the CDF overall and the other projects. So everything has been notified sent in completed and winners will be announced at April 15 or the CDE con which is the week of April 15 in Seattle. So good luck to everyone who has been nominated and was up for nomination. And thanks to everyone who voted and participated in the process. Next up we have Google Summer Code. So things are moving well on there. The application deadline just passed us on April 2. So we've got something around 75 valid applications which is great and 40 or so good proposal good proposals or at least draft proposals for a GSOC project. So lots of participation lots of great work being done. And so the the org admins and mentors have been reviewing projects and will be submitting what they end up deciding upon or having a unison for in terms of the ratings. And then that process essentially is we submit the projects that we think will be successful and be a good experience for not just Jenkins but the GSOC participants and the whole process as a whole. And then if Google approves will find out from them and continue forward with those projects. We're really excited about this. There's been a lot of great activity in the Gitter channels and the matrix channels whatever you want to call them between Chris Bruno other org admins and the potential participants it's just really great to see. And really heartening to know that people are really excited and gearing up for this. Is there any other notes on Google summer code that we should mention or anything that is a highlight that we want to share. Not really. In fact, I know for a fact that we as mentors have to finish our grading by April the 19th. But I don't remember the next milestones. I think it's a week after April the 19th that we will have to tell to Google which one would like to be selected but then I just can't remember when Google will answer say okay you have 234. I don't know how many projects that they will fund for us. So I don't know. Yes, we'll see. There is no emergency for them being we still have a few ducks office hours before I know my numbers and milestones. Thank you so much Bruno. And if I'm not mistaken usually the timelines in the May areas when the community engagement and report building starts to happen so we'll know soon as you later for sure and you know and that'll kick off so great. Awesome thank you so much. Next up so we have the version docs project. So this took this had to take a backseat for a little bit just because the infrastructure team was working on getting the cloud costs under control a bit from there were there were a little bit higher than we wanted them to be so there's priority number one. The team has since gotten a lot of that under control and is much much better situation than we were in. So this now gives us the opportunity to have the version docs site project come back into the fold of what's being worked on. So, right now, there's plan for the data, the update center move to be completed by April 30. Again, the highest priority is making sure the cloud costs are covered. And then once that's taken care of we'll get back to this Vandy and Chris Starn have been working on this consistently and making sure that everything looks good. I've been reviewing things as I as they come up and come along to make sure that there's no working pages that navigation works. And we're able to meet with Daniel Beck as part of the security team to make sure that their advisories process is not interrupted or imposed upon in a negative way. So, great news there we had a really great session and I think we came out of it with a really positive outlook for the version doc site from, you know, our internal and infrastructure perspective but also from a security perspective. Daniel Beck was very satisfied hearing that it'll work a little bit faster and be a little bit more secure in that sense. So, really great stuff there. I still need to do a little bit more detail review on some other things before we finish up. But I've gone through a lot of the installation of the installation docs and a lot of the just different sections there so not too much more just the things that I forgot to check out or stuff like the developer docs that may not have been first pass. So, more to come on that. And does not appear that my leader Chris has joined this time so there won't be a demo this week, at least during our session. There may still be a demo later on at Asia Docs office hours, which there will be a same the video recording and everything will be available afterwards so always check that out and include it here as well. So, more to come on that in due time. So, this is an update for the Docker compose tutorials that have been worked on and completed and submitted and merged by Bruno. There was a recent fix introduced in Docker compose version 2.24.7 that rendered the existing Docker compose YAML and valid. Bruno's already been on top of this he's created a couple PRs that are designed to fix the issue. They're currently I think ones in draft mode I don't know if the other ones in draft mode still but they'll need review and and everything prior to being able to be merged. But it does need does require or it's best practice that they be merged at almost the exact same time so that there's no instances between the two being merged. So, Bruno any insights notes anything you want to share on that stuff. Yeah, thank you Kevin. What I saw earlier is that 40 people forked the repo, which is not necessary to run the examples but that means that some people try to use it even to modify it I don't have the numbers. I don't know how many clones were made but for me that's an indication that people are trying our tutorials, and that's a good sign. And more than that, there's two, I think it was two more could tell me if I'm wrong but two people just declare created an issue as saying that it was not working for them anymore so some people are using it and even are reporting some issues so I'm happy about this situation. What I'm not happy about is of course that it doesn't work anymore. That's why I created those draft PRs. I think is we were using a functionality. I believe that it's not really bug it's a functionality that was poorly documented or not documented at all. So we were really at the border of something working almost by accident. And then somebody proposed to fix in Docker Compose 2.4.27 and then all of a sudden our work couldn't make it anymore. So, yeah, that's a bummer. So I had to, we work our existing Docker Compose file and work with profiles. We were already declaring profiles in the preceding version of the Docker Compose file but not really using them so this time we have to use the profile extensively. So my proof of concept does work but I may have over engineered this. I had a discussion with Damian earlier today. Thank you Damian for the insight, by the way. And it told me that I did something that was maybe too complicated for the goal we have just having something that works. So I will simplify my proposal and get the PR out of draft maybe tomorrow hopefully so that we can then merge after a review the PR regarding the code itself and then the tutorials. And as for the documentation, the tutorial themselves, frankly there is not much that has changed. The command has gone from Docker Compose up minus the Maven to Docker Compose minus minus profile Maven up. So that's still easy to get it to work. And I think that's all I had to say Mark, would you have any remark command or question about that? I'm curious on Damian's observations about complexity. Was this, is he not okay with the use of profile or is? Oh no, not at all. It's okay with the use of profile. The thing is I have some kind of new sidekick Docker container that tries to trick JCASK and Jenkins controller to restart with on the fly generated JCASK token. It could work. It does work sometimes but not all the time. And frankly, it's not really a problem. The thing that was bothering me is that if we don't do that we have to declare in the Docker Compose file a token that will be used by JCASK to know by the controller to restart the JCASK import file. And I didn't not like that. I didn't want to have anything hard coded in the Docker Compose file. But Damian said, it's okay. You know, it's not production. So you can, of course, use hard coded token for that kind of work. And frankly, what would you prefer having something that is generated on the fly but this is setting to restart your Jenkins controller or just something that is hard coded but that will allow to restart only the JCASK import. Okay. I'll go with the hard coding string. That's what I call the over engineered over complicated because there are lots of steps. Yeah. Okay, it's you adopted a more general solution than Damian and Damian said, hey, it doesn't have to be that general because if we make it very specific, it's much simpler. Yes. Got it. Okay, thanks. Thank you, Mark. Thank you very much. We're really appreciate all the insight you shared and clarity. Thank you. So next up are a couple of newer topics for us. So, first is technical review and validation for pull requests. This is something that I've recently been discussing with Mark and bringing up. So, when it comes to pull requests coming into Jenkins.io, I am first and foremost a documentation person, not necessarily a developer so some of the more technical aspects and code are a little lost on me when it comes to testing or trying to verify. So, what my deal is that we have, we reach out to the community and first of all see if anyone is willing or able to provide assistance in this area. And so the idea is that we'll find people that are willing to help and okay with me reaching out or tech or a tagging them for review. And it would be strictly technical technical review and validation. Again, things like code blocks configuration settings. Things that I'm just not necessarily doing on a regular basis, plugin development, things of that nature. There's been a few, there's been a handful of submissions to the developer documentation specifically that has kind of pushed it a little bit further in my mind. I don't want to create any issues and I don't want to, I don't feel comfortable submitting anything or merging anything that I'm not 100% sure of. And so this is an effort to make sure that the documentation or any content that is submitted to Jenkins.io is correct and validated by someone that knows. We have migrated previously from the wiki to now Jenkins.io. And I want to keep up the quality of documentation and content that we're putting on this Jenkins.io. I think it was a little bit more wild west and that anyone could submit. And so I don't want to remove, I don't want to raise the barrier for entry or make it harder for anyone to contribute, but I want the contributions to be correct. Valid and so that we're not creating misinformation or I'm not putting anything to the documentation that should not be there. The documentation of urgency or immediacy with any of this. It's something that can be done when the person has free time or has space and capacity available to take a look at that. It's not something that will be done as a first pass. I'm still going to be doing my normal documentation review. I'm not testing everything as much as I can and getting to a point where I actually have exhausted everything that I know or just can't anymore. And at that point in time and only that point in time would I be looking for further assistance and validation on this. Regular documentation reviews things that I can take care of myself things that are not as involved or as beyond my skill set. I can handle, but when it comes to something where there's a configuration file that needs to be set up and I'm just not familiar with that process or like what should and should not be there. Asking for another set of eyes someone that has experience with that and something that I would imagine or would hope could be, you know, realized a lot sooner than if I were trying to figure it out. It's not something that we want to have anyone take a lot of time for. It's something that you would ideally be, you know, 20, 30 minutes at most to take a look at this and review. Not anything like coaching or providing a lot of like back and forth conversation with the contributors. I'm more than happy to take that lead on that. Even if it's, you know, providing those suggestions and feedback myself even directly, if I can sit down with someone and they can show me what's going on here or explain what's wrong. That's going to help me grow that's going to help me learn better and be a lot more confident in just these reviews. So, there's no idea of commitment there's no one person that we want to rely on either I would love for this to be multiple people so that I can just reach out. And if someone sees that someone else is already looking at it or has done the review they don't even need to worry about it. Because that's not fair that's not what we're looking for. And yeah, ultimately this is more to make the experience in the process just a little bit smoother overall, and make sure that contributors are putting in the work that they are doing but making sure that we're not, or that I'm not merging anything that shouldn't be merged. Now, all that being said, Mark Bruno thoughts feelings concerns questions anything like that on this. Yeah, so I think it's a good idea we've already got a first step, thanks to the work that was done to recently add more people to copy editors. And, and to the docs team. So yeah, I think that that's good now. The catalyst for me that I like that you've done this Kevin because there was a pull request submitted that was proposing to change the release the reverse proxy instructions for Linux IP tables. And the thing that the author submitted just didn't work. But in order to test it you had to know Linux IP tables well enough to diagnose to see what's happening to watch it fail, etc. And, and that's not not a common set of skills. And it's, and it's something that like I said, it's a newer contributor that's trying to be part of the project we want that to happen that's not something we want to take away or like I said put a barrier up. So, if I don't know that but I can say hey, if someone happens to know about this and you have five minutes could you take a look and just like confirm deny whether or not that's the case. I think the best case scenario at something quick and easy that someone who knows could look at and say yes or no. Obviously it's a little bit more complicated it might take a little bit more but Yeah, I think, I think you're optimistic that that it won't take long the the IP tables thing was relatively few few commands to be tested but getting to the point where I could test it was easily 30 or 40 minutes. Even even that better to have spent the 30 to 40 minutes than to have published something that simply does not work. Yeah, and that also makes me think of PR we got earlier this week regarding Maven settings dot XML. And I think that what was proposed was not working or not necessary and frankly if you don't test it, if you don't have the machine that could. To do it, you have to test it you just can say oh that will work because you don't have the compiler or whatever in your head. You have to test it so yes it's a very good idea to have a set of people able to help with maybe more technical things you have to get your hands dirty. Well and on that that Maven settings that you noted I think we actually already have a page that describes the Maven settings and so it may be that what we ought to do is we need to deduplicate that page so that we get a copy of it that we can reuse in multiple locations. I was surprised when I discovered the the other page, the existing page that describes settings that XML because I didn't know we had one. And that way if it's wrong, we fix it in one place and it appears correctly in multiple locations. Yeah, good insight. Thank you. Thank you Mark. Appreciate it. So yeah, so we're going to continue having a conversation and looking to see if anyone who else would be open to joining that. We've already had a couple of people added to the team as Mark said, thanks to the info team for all their help with getting those permissions set up and adding members to the team. Next up on new topics so documenting pipeline libraries with markdown or plain text or HTML. Mark added this topic but Marcus winter had proposed this in a pull request to support markdown for pipeline library documentation here. And yeah, I'll bring that up but Mark if you want to kind of just describe what's going on here the idea Marcus had whatnot. Yeah so so I like so what Marcus was suggesting is that when someone creates a pipeline library. And we have a very good example of that on ci.jankins.io where every plug in and actually a number of other components have a very small Jenkins file. It's build plug in with a few, few arguments. And all the heavy lifting is done in this shared this pipeline shared library. The documentation for that pipeline shared library is written in HTML or in plain text. And HTML and plain text are workable, but most of us are now comfortable writing things in markdown. And what, what Marcus is suggesting is hey let's allow pipeline libraries to be documented with markdown. And so I think it's an interesting idea and I test drove it. I am a maintainer of the markdown plugin. So I and the markdown plugin is already installed on my Jenkins controller. And I modified the pipeline documentation for the pipeline library used by ci.jankins.io in my private for right so or in my my fork it's not private but in my fork on this my own master branch. And you see that the changes aren't really dramatic. It's not a huge bunch of changes. Instead of href it uses markdown style syntax for hyperlinks. The asterisks in the lists were I think already being interpreted correctly by by the I'm not entirely sure on that one so in this case. This one may have been be much better now because HTML would not have interpreted the asterisks correctly. And, and so there is there is a real improvement here by switching to use markdown. The, the simplification but the problem is it would require that we install the markdown formatter plugin on the Jenkins controller and that means persuading the infra team that markdown formatter plugin is not a threat. To the stability of ci.jankins.io and and that's a valid valid concern from them because they have to provide ci services for thousands of plugins right for Jenkins core for Jenkins documentation for all sorts of other things. So yeah I'll I'll start the conversations with the infra team and with others and we'll see where it goes. Thank you very much Mark I really appreciate all that explanation context. I just linked the since you mentioned it in the Jenkins new per channel on kid or I just thought I'd throw that link in there as well since that idea like you said the idea is being brought to all the other areas of Jenkins so. Fantastic. Thank you very much. And then the last item here. And we talked about this in the technical validation. But we got some new members fitted on to the docs team the wiki docs team the docs team in infra and the copy editors team. So thanks to our they tend to calm the team for all the work on that and getting that sorted a little bit better. That also involved removing older members that are no longer participating in that sense. So just a nice little spring cleaning for that. And that's one where we we generally don't want to make changes to that repository right changing the the archival copy of documentation is really a bad pattern. However, in this case, we had a plug in whose documentation was in Markdown or no in the wiki, we needed to mark that plug in as deprecated. And we didn't want to release a new version of the plug in just to declare it deprecated. So by editing the files on the wiki archive, we were able to market as deprecated. So, if you're willing to open you can see the result of this change on plugins that Jenkins that I'll, and they're look for the word peg down PG do WN. Yeah, hit control f five it's cashing itself. You're seeing the same thing I did and I'm not entirely sure what's. Make it easier just put on the end of the URL slash slash peg down PG do WN. Yeah, dash formatter. Okay, that's that's probably fine too now if you if you search again. There we go. Yeah, so that note actually was added automatically by the generation. The thing that had to be changed is below the bar below the documentation button. Where it says peg down formatter plugin deprecated that piece did not exist previously. Got it. And now it does and it includes a link to the markdown formatter plugin that is not deprecated. So when we deprecated plug in we really like to tell people, go here instead. And that's what this is doing is I had to insert a way to tell people go here instead. Right, right. And then now we have the link to the markdown format or plugin. Right. Great. Me cool. Well, that's a new little trick. Thank you very much Mark. That's it for me. Great. And that's it for the agenda as well we're a couple minutes past time but thank you very much for sticking around. We're under recording in just a moment it'll be available in 24 to 48 hours and as always take care stay safe and we'll see you next week. Thank you as always. Thanks. Thank you.