 Recording is on. Thanks everybody for joining Jenkins Docs Office Hours. See, I need to find our notes. I've assembled them. And here they are. Okay. So Jonathan, since you're here, any questions that you have that you'd like to start us with? I didn't see our agent until today. Today was just Q&A. Just question and answer. No, I have just a... I need some clarification for you. I would like to have your opinion about the PR that I created some days ago. And if possible, I would like to have more information about the Community Bridge too. I read all those links that you provide to us, but there is no valuable information to members to send their proposal. Maybe I didn't find it. No, you are correct. We are not ready yet. I don't think we're ready yet anyway with a process that proposes how people would send a proposal for a Community Bridge project. Yeah, I don't understand the workflow process to work on. Right. Well, so let's put that as a topic and we can discuss it. And so Community Bridge proposals and topics, right? And workflow. Okay, good. So I'm actually going to go ahead and share my screen and we'll just look at my screen as a... as our source for the notes and we can talk to it there. That's... it's certainly no worse looking than I am and is a lot more organized looking than I am. So there we go. We can argue that, but... Yes, yes. That'll be enough. That's great. So Community Bridge is... we don't have a project proposal workflow defined yet. In the past, in the past Community Bridge project, we reused the Google season of code proposal workflow. Now it was a code project and therefore it fit to use Google season of code. I would assume we'll reuse the Google season of docs process for Community Bridge. So right now that would mean we would draft proposals. They would go to probably the Jenkins governing board for review or to the mentor team for Google season of docs. And then a project would be selected, that person would be funded and off we would go. Now is that what you were asking, Jonathan, or is there some other question? Yeah, yeah. Just for clarification I asked for, because I have some doubts about it. But what do you need to... we need to prepare something. There is some timestamp to work on, like a stone mark, like a timeline or nothing. Not yet. Not yet. So just let's wait for it. Correct. Right. The first, the most crucial thing here is funding and approval to do a Community Bridge project. We'll have to come from the, comes from the governing board from the Jenkins board. And that hasn't been granted yet. And so that's the most crucial thing before that until that happens. Right now, our total dollars sitting in Community Bridge to use for this is not enough to fund it. And so, so we would, we may have to request more funds, or we may have to request donations, or etc, etc. Okay, so we can wait for a signal from Jenkins organization. Right. Right. So wait, wait for an announcement and it will be, it will be made very publicly, right? So, of a Community Bridge project. So the last one we did, we did with a blog post. We did with a mailing list announcement. I don't, I don't think that we would do a webinar for this one, but we might even do a webinar that's, that's a possible for sure. In the past we've used blog posts and mailing list announcements. Okay. I would expect we would in the given that now we're using the Gitter channel we would likely also announce in the Gitter channel. I wanted to, to comment on this in case if participants of this special interest group, or like any Jenkins project participant participants can facilitate funding, please let us know how can we help. Oh, great. Okay. That's a, that's a very good question. Let me show one example. This is when you might mention to, to others with whom you work or to employers. So if we look at the Jenkins Community Bridge page. We're accepting donations. And let's see where is it. So you could pass for instance to an employer. Then you say hey we would like you to contribute to Jenkins Community Bridge and now I may have to go find the correct location just a minute while I go looking. It is not there, but there. Okay, so there is a donate button somewhere in these things. Donate, where is donate. Maybe I should just do it like this. I know there is on GitHub on different. Oh, yes, yes, that's a very good suggestion I should just go there because of course it also exists there. I think I can find it here. I'm contributing down. Okay, so because I know that the donate page has been added. No, that's not it. Okay. So it may be that it's still in progress. So let's use Vlad suggestion and go to GitHub. And get up. And I think if we look at core, I believe it's been enabled on core hasn't it. No, I don't see sponsor sponsor sponsor. Oh, that one. Yeah, there we go. Thank you. Excellent. Okay, so this page shows us that we could. And so individuals and organizations can contribute. Yeah, I believe this $3,000 expense that you see here was what we use last year to fund the Jenkins Community bridge project that we ran last year. So we would be delighted to have more contributions and big green donate button. Thank you. Thanks for guiding me through that. Sorry for my lack of skill, but yes, that's that's that's the way to get there. Any other questions on community bridge. Hey, we had another topic here which was Google season of doc proposal details doctor solutions and tutorials. Vlad was this one you had asked or is there somebody else who'd asked that one. I actually added this. And this is a follow up to our submission of proposals which I guess happened last week. And I would like to address my, well, my proposals, I just wanted to keep them somewhere. I posted today a question on Docker discussion group and got response from Alex that nothing is developed regarding to my proposal. And it was basic proposal was about creating something very simple, which will allow to generate set of Docker images with Jenkins inside. Something similar to Marvin archetype, for instance, archetype generate you can create different archetypes up to 15 different solutions predefined. And we can, well, just an idea do something very similar to this. The main goal from my point of view is simplicity of this kind of tool or plugin I have no experience developing Jenkins plugins. So users can very easily build and instantiate run Docker image which will do something very specific. And the specifics will be defined by Jenkins project or by by Jenkins basically community bridge, and the user and user will need to choose between solutions which are more appropriate to his goals goals. And again, there is like wide range of different possible solutions. And I would start in case if I will be allowed to implement this from simple one and go up like increment complex complexity, not vice versa. So kind of bottom to up approach versus top down. So, yeah, I will start with Kubernetes but go eventually to Kubernetes. And I think the idea is interesting. The, the we have tutorials currently that for instance run run an agent so run a Jenkins plus an agent to build a Maven project. And we have a Jenkins plus an agent build a node node JS project and Jenkins plus agent to build. Let's see what's the other Python project. And so, so you've got some good working base to think about it. How to go. Were you considering. I'm assuming you were not considering other components in in this Docker image. So, for example, not considering placing a source control system inside this image. Probably not. Well, it depends how we run this. I guess. So if there is like volume will be mapped to the source then during this situation place. It will be this image will have access to the sources. Yeah, you are just my main goal is to attract new users so they will become adopters or Jenkins so we can increase their user base I know it is like already significant enough but still like. And the reason for this is for the simplicity. I believe this is how main technologies got very popular like how Internet appeared basically HTTP HTML is very simple kind of approach solution versus previous attempts. Or like rest restful approach is better than simpler than so that is why it was adopted by industry. This kind of idea so simplicity is the key for adoption. Because like Jenkins is already complex enough. So, we already have good base of professionals, like programmers, computer scientists and so on working on this, but something like to popularize it and make sure that like, My, let's say, virtual grandmother or virtual granddaughter will be able to succeed all virtually. There is no such person, but they will be able to run it by simple command and create Jenkins apps. Now, regarding this tutorials that you mentioned in the previous paragraph, I guess they exist but they're using how to phrase, not official Jenkins image they're using blue ocean. Jenkins evolution, which is my understanding is deprecated kind of not supported any longer. It's, it's not only it has very specific problems that we would like to get away from it. Absolutely. Yes. So those tutorials are are flawed in the sense that they're using an image that then if users if users say, Oh, I'll base my work on that tutorial. We think they've made a mistake, right, rather than basing themselves on the blue ocean image they should base themselves on the production Jenkins image. But that's that's disconcerting for them but I just did the tutorial on blue ocean on the blue ocean image and the answer is yes that's true you have to make that disconcerting transition. So if those tutorials could be switched to to not use blue ocean, that would be a win for the users for the students for those who are studying. I may mark a comment also, instead of saying not using blue ocean. I think blue ocean is very interesting attractive plugin, not using the ocean image, not but blue ocean plugin maybe still included through plugins, text or whatever inside plugins. You make an excellent clarification, absolutely wholehearted agreement that we don't want to. We want to in fact encourage them to use the blue ocean plugin to visualize pipelines. It's an elegant way to do it to do pipeline editing and visualization it's very very powerful. Using the blue ocean docker image is an anti pattern. It's a negative because of the problems that are in there built into the blue ocean docker image. Yeah, good, good clarification. Thank you. Now Vlad, I think you saw my note on the custom war packager. As a, that one is a relatively exotic thing I hesitate to, I would not envision us being able to tell a new user of Jenkins. Oh just use custom war packager to define your own completely custom Jenkins instance. That's, that's to me just too complicated for them. It is certainly an excellent technique for experts. Oleg makes very good use of it and others make very very good use of it. But the custom build service. Jenkins custom Jenkins distribution build service is working towards what could be an end user acceptable and end user usable. Ready to go you define the configuration you want or pick from a menu and conceivably we could have have something that says oh you want to run this tutorial. Fine go to the custom build this Jenkins distribution build service and choose this distribution. And then they would get the this custom probably docker image that's built for them or custom something built for them. That would meet their need. I know that this this project is part of Google season of code, I guess season or some of code. Properly. Although my understanding was that this specific project was targeting UI so users through UI will select what they want to build by clicking proper plugins or whatever. I was thinking about doing something from CLI kind of tool which you can just like put some option. For instance, whatever name of this tool or whatever, generate or create or run and option like number for instance, and this number will be mapped to one of our solutions which we predefined based on something to decide based on statistics, the most popular solutions the most widely used less issues well whatever would be the most appropriate rule to define this kind of solution. But, but you're right, I need to like look more closely into this project. Definitely there is some kind of overlap in the section. And again, I'm putting this for discussion suggestions and so kind of follow up and providing more details to ideas which I submitted. Any other questions or topics you'd like to we'd like to bring to the discussion. Wow, can we speak about the DPR that I said at the beginning. Absolutely. Let's do that. So that's, and which were the PRs Jonathan. Yeah, I sent it through the chef the chef. Perfect. Let me grab it there and let's take a look at it so 3481. Yeah. Okay. Okay. So, some days ago, Oleg recommended not to use raw HTML HTML and the right documentations. But that's the P this PR and the that one other. I, I use the already imported bootstrap to create this effect of to go visualization. Are you seeing on the gift. Hit the button that show you the help or not and you choose see or not in the image. So as the back does not offer to us a feature to do this. So you will, you will prefer to keep this button with raw HTML or you recommend to remove it too. So I would tend to advise removing it, but let's let me look at something different. Let me show you a different one because there is a thing that does we've got something already that does a hide and unhide in a different context that we might be able to use or might be able to use to justify the technique you're showing us. Let me see if I can find it here it is in the plug in the pipeline documentation. If we look at pipeline syntax, I believe it is. There is a section which will show us this is purely declarative. I may need. Okay, pipeline syntax reference. Okay, there's declarative Meg, maybe you know where it is I. There is definitely a segment where I can see. See using doctor maybe this is okay let's see. Yes, there it is good. Okay. So, let's see first question can everyone see my screen okay. All right, so here is here is a segment of the document that describes using Docker with pipeline. And we give the preferred solution first in declarative pipeline declarative has the benefit that it, it is immediately parsed in its entirety. So if there's a syntax error late in the in the pipeline it's detected immediately scripted doesn't do that. But some people have found that hey they have to have scripted and so we have this here which says toggle scripted pipeline, and it presents this other thing. Now, I, I haven't looked in detail Jonathan to see how it does this, but I'm pretty sure it does it without without doing too much JavaScript without doing I suspect any JavaScript magic because the people who worked on this particular thing I don't think we're JavaScript programmers. Yeah. Yeah, it's quite complicated, sorry. That solution but I will replace it. I wish that there's the one and replace it. Well, at least compare it I'm not sure I'm not I'm not confident yet to say who you should replace it. But if you compare what this technique is. This technique is helpful because it in this case does I think what you were trying to do which is initially the user benefits more by seeing the list of steps without seeing details for each step right there's, I need to know that there are five things to do. And if I put the pictures in there all the time. I don't use track of the fact that there are five things to do because the pictures obscure that, whereas if I could toggle to see the picture expand. Yeah, it's much more understandable. It's the same idea that Vlad tells us it's to keep simple. So, no, no is visualization with you in the first contact you have a lot of information you get lost. Why will you read my study. So I will study this link that you show to us and if you work well I will replace it. Well, and I'm going to put that into the notes just in case so that is a place to alright so. So let's take a look at that. Let me make it so. Pull requests. Discussion. So it was PR 3481 which had the expand and contract. Unhide and unhide images. Sitter this. Yeah, and I wrote to the PR and I opened the issue to to create a plugin to ask doc. So if you come back to get visualization there, there is the link to create a new plugin. So that was the description at the description. Yeah, the first. Oh, yeah, yeah, second bullet. Okay. So, in fact, I, I wrote the code, but I'm not I'm not a rugby expert. Do you know something in our group that have have the expertise to write plugin to to help me in some question. Well, I know that Daniel Beck has done it. I know that I will be using some Ruby code to do a thing that I need to do for the Jenkins infrastructure page. So I'm going to be getting into it. But if you're asking somebody who has Ruby skills that is definitely not me. I am willing to experiment and learn. But I certainly know people who have written code in the in the Ruby here like Daniel back. I think he has as well as your clinic connection he has based in I believe he's in. Okay, I send a message to all again. So maybe he's answering the next two days. And I come back to next help to YouTube. So, if I can't resolve alone. Great. All right, so that was the first is the is the second to the same. It's the same as just for over samples. It shows our two different phase one about the parameters building. And the second one is about the agents. Excellent. Now, would you be willing to share a tutorial with us I am truly impressed by the scrolling image that is here. How did you create that. You're able to do that same technique. Yeah, it's a help to the review review to see review the change. I can make a tutorial and I think to you. That would be great. If you want to just record something. That's great if you want to just tell me that's fine I I've just I've seen people use this kind of technique where they'd use what I thought where it must have been animated gifts. And it's marvelous. Okay. You just need a program to recorder your screen. So you export the key part in the website that support this. And so you can put a hdm tag image tag. It's on this. Okay, great. I will send you which page. Oh, that would be wonderful. Thanks very much. Jonathan, I had done this sometime in the past by already forgot, if it is possible, I would like also to get your. Yeah, okay. I use it. Okay. I'm sure I misspelling your name Jonathan. It's correct. Oh, very good. Yeah, I've, I've fallen in love with my full page screens capture plugin that I use with. Google Chrome, but it's a different thing than, than scrolling gifts it just gives me a static image whereas you've got a way to show images that look like a movie. Yeah. Some documentation website to use a lot of gifts to show complex steps for the users. Nice. I use gifts to my PowerPoint presentations too. So while I'm talking with the people that gives is running and background. It's easier to show samples while presentation. Nice. Thank you. Any other questions. I received a mail from Google season of dogs, just asking for to confirm with the hours organization. If they receive our proposals correctly. It's so you receive the everything it's okay. As far as as far as I can tell from old age reports. That's a good question has the organization receive the proposals. Yeah, they just asked for confirmation. And the answers as I can tell is Oleg reported to the mentors that we have received it received them. Okay. Now, we did have a he's he is Oleg is currently assembling the links to all the mail messages. He did have a surprise. I was surprised when Google season of docs sent the proposals to the Jenkins docs mailing list. That was not where we expected them to be sent we expect expected them to be sent to the organization administrators. We saw them like detected them and has has been able to get what he needed out of them. So we think we have all the right information. So and the reason that was a surprise is the the list did not accept those postings. And that was really a good thing. Oleg was really worried because we didn't really want everybody's proposals sent by email that was we assumed we would review through the website and be able to give feedback and ranking there. Was that clear enough. Yeah, yeah. Any other questions. Not for me. Go ahead. Just general question. I wanted to ask, somehow related to what we discussed today about using, for instance, plug in plugins.txt file in configuration as code while we're building, for instance, our own configuration of Jenkins. I mean, what if somebody knows what would be the best approach or best practice for configuring this set of plugins. I mean, the name of plugins and versions. Is there kind of standard approach for doing this, or maybe there is some tool to generate this plugins.txt file. We need to base from the previous configuration of running Jenkins application, export this file, something like this. What is the best approach for doing this. Because general idea is very attractive, very interesting to include this and this docker image will be configured with all these plugins, but how we generate, how we create this this text file, which is very simple kind of in format. But about the contents, how, what is the best way of doing this. Right, right, very good. So, so there is a, there are several ways to generate that so several different ways, right to generate it to assemble plugins from a list. There's plugins.txt. But that requires that you must must enumerate and this is in the docker image right in docker for image definition. You must list every plugin. So it does no dependency analysis. You just must list every plugin. Mark, are you sharing correct screen. Oh, I don't know. Let's see what do you, am I sharing a screen, I think so do you see my typing. Good question. Yeah, I'm here. Oh, dear. Okay. So let me stop the share and I'll restart it just to be sure. Okay, so you should see a Jenkins Docs office hours screen. Yes. Okay, and ultimately so ultimately this one. You must list every plugin, including all dependencies. And there is another way to generate that same file using the plugin installation manager, manager tool. The same tool that was created as part of last year's Google summer of code. And what it does is you give it a list of relatively few plugins. And it will grab that those plugins and all of their dependencies. But this one is not yet integrated into the Jenkins Docker image. Certainly on the list, we want it done there but it just hasn't been done yet. It is integrated right now inside all eggs demo configuration as code. Correct. Yeah, so, so one of the, the install dash plugins.sh is reads plugins dot text and downloads files. And it is integrated through the Docker image. So now how to generate that list. I think was your original question Vlad, how to create a plugins dot txt file. And the technique I've used. This is a terrible thing to admit that the technique I've used is I go to my Jenkins installation. Let's go there. And in my Jenkins installation, I go to the system info page. So that's manage Jenkins system information. And then if we scroll down after environment variables there's this big table of plugins. I copy and paste from this thing. There's a little bit of editing magic to turn it into exactly the things that plugins dot txt needs. So this system info page is all that I used. Now that is that is a flawed and terribly imperfect way to do things but it worked for it met the need that I had at the time. So basically you derive from running image something that you know it's good enough. Correct to copy and paste. Right and that that has the benefit that I absolutely know I've satisfied all dependencies because Jenkins did the dependency resolution itself. Now I've used another technique. But this one is not not viewed highly favorably by others so I wouldn't claim that anyone else should do it. I have a get repository that has large file support enabled. And I just check the plugins into that get large that get LFS repository. But that requires that you pay GitHub extra money each month in order to be allowed to use LFS. It's just so so convenient for me that it was it was easily worth the few dollars a month that get help charges to use large files. I'm not going to put that in the notes because it's one that I don't think anybody else should it should emulate it just happens to work well for me. So glad did that address your your question there. Yes. Now I, there are there are probably better ways to do it than either of those. It seems likely. I just don't know what they are and so then it'd be best to ask him to get her channels. Any other questions. I just want to ask one more question and this is related to the issues are general approach are in Jenkins project is my this is my understanding that some of the issues are tracked by GitHub. We have GitHub issues for some components. And some components. are tracked by Jira. And I was trying to find out if you have specific component how to determine the application which tracks these issues. I visited GitHub or Jira, and I found solution like if you go to GitHub, the project name and component, let's say Jenkins CI Jenkins slash issues. It will redirect to pools. So there will be no issues on GitHub only pull requests. It means all issues are tracked by Jira. Or maybe there is some other solution so or approach. I just was wondering. No that you described it well. So you're the heuristic is assumed Jira is the place where the issues are tracked as your first choice. If there's a question is Jira actually being used check the source code repository. And if the issues issues tab is enabled, then it's tracking issues in in GitHub. So the example, let's see let's let's take two different examples there's the first which is the Jenkins get plugin. So plugin I maintain. You'll look here and it does. Oops, it does not have getting used to my new mouse. So, across the top here code pull requests actions projects, but no issues tab. If we take a different different repository let's take the Jenkins.io repository for instance instead. This is for the website. This one notice that it has an issues tab and has good content in the issues tab so it is in fact using GitHub to track its issues. This is one where the Jenkins.io site comfortably can use GitHub to track issues, whereas the Jenkins get plugin intentionally does not use GitHub issues, because GitHub issues do not have a simple direct way for us to manage security issues inside GitHub issues. So we've we've had to be more sensitive there. Now back to your question, Vlad. How can I tell, and the answer is, check the GitHub source code repository. If it doesn't have an issues tab they are certainly not using GitHub issues to track. If it does have an issues tab. It's still safe to check, is there a Jira project where they are tracking those issues. I'm not sure I'll bother opening Jira for you but it's the Jira issues are definitely there. So we have components which are which issues are split between two applications. Well, we have we have, I would say we have components which are in transition. And components in transition typically are going from Jira towards GitHub issues. One of those components in transitions is the Jenkins.io site. We initially tracked its issues in Jira. And we found it was much easier for users and much easier for contributors if we switched that site to use GitHub issues but that means there are still some some old issues in Jira that we are slowly closing Thank you, Mark. All right. Any presentation at Hackfest. You and Oleg and speaking about some plugins that are ready for adoption. What that means? What is adoption to are depreciate plugins or underdeveloped ones? What is what means adoption? Good question. Very good question. So what does it mean to adopt a plugin or for a plugin to be up for adoption? That's an excellent question. So on the plugin site, if we look there, what we'll see is there are labels that are associated with plugins. I have to think of one that might be up for adoption. I think the subversion plugin is up for adoption. Yeah. Sorry, Meg. What was that backup? There's a bunch of backup ones. Okay. So here is there's a if we look at the here's my example. This is the subversion plugin. So if you were a subversion user, you might see that you would see this, this indicator which says hey this plugin is up for adoption. And on the adopt a plugin site, it tells us what that means to adopt a plugin. And plugin maintainers can say hey I'm not planning to maintain this plugin therefore they market for adoption. And other plugin maintainers may say hey, I would like to adopt that plugin. So you follow this set of steps right here. You can email to the Jenkins developers mailing this saying I would like to be made a maintainer. And in that email you tell them which plugin you want to adopt. Pull requests that show that you're credible. Your GitHub user ID and your Jenkins user ID. And, and then you go to work on it. And how does the expectation about just approval some PRs or keep maintaining and in the future, offer them to adoption again. How does the logic behind. So the assumption is that you will, you will make some positive impact. Usually the reason someone adopts a plugin is they would like to release a new version of it. In order and in releasing the new version of it they want to make some changes either. They want to update it to use the latest Jenkins versions or they have some feature they want or some pull request they want there's usually some motivation that says I would like this. And therefore they adopt the plugin so they can do it. We hope that they would then continue maintaining the plugin. But that's, that's up to them, they will be listed as the maintainer, and then they get to choose do I want to continue releasing new versions or not. Okay, and there is another tag that said abandoned. What is the logic for transition from adoption to abandon it. It's just. So abandoned, I think is not actually tagged. I don't believe. Let's see if we've got it. I don't get the subversion plugins that it's set to with abandon it. Oh, did it. Okay, let's look. Okay, so let's see. So when you you click on adoption plugin, click on the link. Oh, I see what you're saying right so there is a plugin. Right. The second paragraph. Got it. It's this right here. But the concept of an abandoned plugin is not labeled on the plugin is not not a label you will see. It is merely an observation made by looking at the commit maintenance history of the plugin. So for example, actually, let's let's take a very specific example. We can find one that Oleg originally wrote, but he no longer maintains called the remote loader plugin. Let's go look at it. And it was released there are plugins that were released last for instance last release nine years ago. And, and a plugin that was released that long ago is probably abandoned. See if workflow remote loader is that way. Here we go. So, oh no, this was last released only a year ago, so it's relatively recent. But there are other plugins that I've looked at very recently where the plugin was last released a very long time ago. And that's, that's where we would apply the rules and say, Oh, this is probably an abandoned plugin. And so we need to follow the abandoned plugin adoption rules. Okay, it's just far for us to thank you for information. Great. Any other questions. All right, then I'm going to propose that we end our session for day today. Thank you. Next milestone on Google season of docs is July 30th, I believe, when the organization proposals will be submitted to Google, and then I believe it's two weeks after that but Google will announce who's been accepted. Thanks very much everybody. Okay, thank you. I'll save a copy of it, and it'll be posted to the list. Thanks. Thanks. Bye.