 Hello everyone, this is, what is it by the way, yeah? We're on the 7th of August 2023, and this is a GSOC Jenkins Dockerbase Quick Start meeting. Yes, it's not the meeting which is Quick Start, it's the Dockerbase Quick Start title. I'm always puzzled by this one. Let me share my screen. Yeah, after, I don't know, nine weeks, I'm still struggling with that. Go figure. Can everyone see my screen? Yes. I just had a black spot on the document, so now I can see it. Oh, okay. So, I don't think Stefan will join us today. Got it. So, we are on week 32, and there aren't really, yeah, and they aren't that many new items for this week, but we still have some from last week that we have to finish. So, from the things I had noted last week, what has been done. We have the pushed images to the hub, so it has been merged. The forget about pipeline, move to multi-branch pipeline is also done and merged. And get the GitHub action to test the real job. This one was tough. It has also been done and merged. So, we still have the keep the plugin list up to date when building the Docker image. This one is not really easy. Do not build the images for the end user. Reuse private images. We'll discuss this one also. And we also have a little one, which is remove the jcask proxy warning configuration where we're not using GitHub. Before digging all this subject, Ashutosh, would you have anything to share with us from this week? How did it go for you? On the issue, I think it was good. And then testing the real job, I learned a lot of things about the state pay and how to do that. So, I think that was good. And it got completed successfully too. So, yes. Okay. Thank you. So, the real jobs one, let me open this one if it's okay. Let's see if it's readable for everyone. I know it's blank for the time being. Yeah. Okay. Way too small. Okay. No, it's good. Too big. Go ahead. That's too big. Yes. Big now, yeah. Computer is struggling, I guess. Let me, yeah. Thank you. So, up to last week, we were testing all the different dogfies, you know, Maven, Python, Node and so on. And asking Jenkins, thanks to Cole, please launch a job, which was a simple job. We were waiting for the end of the job checking if it was successful or not. And then we were shutting down Jenkins. But we were testing the very same job in each and every configuration, which was fine, but not enough. What we wanted to do is to test the real jobs. I mean, Maven for the Maven configuration, Node for Node and Python for Python. But it was not just taking a config.xml file from an existing job and then put it in the configuration and run it. Of course, because one of them, Node, was asking for some confirmation, you know, what is it? The board or proceed? It was an interactive pipeline. So that proved being difficult. Ashutosh, could you tell us more about that? Yes. So that needed the input. So for that, I modified the Jenkins file and added an input ID in it, which can be triggered with curl command. And I've updated the readme file for it and the Jenkins file in my fork repo. You can, I think it should be as well. Want to share something? Oh, Ashutosh, please. We can share your screen. Can you see? Okay. We can see your screen now. Yep. It's just available for you to small. Yeah. One tick bigger. That's good. Yeah. Thank you. Okay. So I had another issue while testing this. When I added this section for data workspace URL variable, it was working fine with that part, but it was giving an error when we are using it locally because that time this variable was empty. So I've also added the statement for that. And I've added, why is it highlighting? Okay. I've added the input input ID so that it can be shared. Yes. Could you please show us a curl command? If it's not too difficult to dig it up. I even didn't know that existed. That's cool. Nice. Can you see the VS code or only the browser? Only the browser. I don't know how much you have already worked with Jenkins automation via call or maybe Jenkins. Mainly with the. I made me mainly with the upside with the CLI. I did. Yeah. But it's common life interface. My bed. Yes. Because I don't know if the documentation is really well hidden, or if it does not exist. But I think it does not exist. Oh, that's why. Yeah. Yeah, it's hidden in the brain of the people that wrote it. So, honestly, often you need to look into the code itself. I did a little trial of trial and error using it locally. So it worked. I didn't find any documentation. I agree. It's lousy. Yes. So I had this one. Right now it sends the code command to every tutorial if they didn't. They haven't been in time. But it doesn't affect them. So this is the job name. Okay, build number input. Wow. Okay. It makes sense. Yes. And I've also, I was getting an error before this. So for that, I needed the console out for the build. So I've also added this. Oh, yes. In case our job sales, it will give us the console out doing the. Okay. So now you know why it's failing. By the way, did you have, I can't see a sleep before the code that clicks on proceeds. So how do you know that it's already ready to be clicked? Yeah, if it's not ready, it doesn't affect anything. So after understanding the loop again after five seconds, and if it, if it's wrong, do you fail that loop or you stay looping? No, it's the best status fail. If it's building progress is true. It continues the loop. But if it does not complete because there's something wrong with it, it will continually looping. So you should maybe have a count or something. No, it won't continue. We have building progress variable. It will be false if that happens. Building program. Okay, good. Yes. Okay. Yeah. So yeah. When building progress is false, then you get out of the loop. Right. Yes. Yes. And then you have a look at the status. Yeah. Well done. Yeah, this one. Okay. Now that you have wrote on it, it looks easy, but finding the right set of code commands. That was not easy. You know, you even had to find how to write down the console output. So yeah, I was also looking into if we can reuse this because this uses a lot of same steps. So we can use this code in the second, I found something like anchors for bit of actions, but turns out they're not available right now. They're building progress. Yeah. For bit of actions. We'll see if you ever feel like rewriting some kind of bash library or something to get smaller code. There's lots of code is the same along these tests. Go ahead. But if you feel like you don't have time for that, that's perfectly fine. I haven't created a work item regarding that. It works also. I know it won't be as easy to maintain as with a library with smaller code, but do what you can. And fine. Thank you. I also wanted to ask about I was working on building importing the already pre-built images. And I've just used the repository that we have that I created for pushing that opportunity with GitHub actions. And it's working. So is this how in the end will it work? Like right now I'm using my own ID for this, but I'm not sure how it will work in the end. This is where, so this going to execute as a GitHub action? No, the GitHub action gets executed to build the images whenever there is change in the file. And the files get updated. And why do you need authentication here? It is because it's using your name. Right? Yes. I'm not sure how and then what will be what we'll be using and then the project. Normally there is a way to get this when you run it in a GitHub action environment. I think some parts were at least the GitHub user. So when you, when you run this in a context of a GitHub action. I was talking about building and pushing the images that is done using the good actions. This is the compost I'll be used for running the containers. This is the main one. Right. So let me try to refray that just in case so that everybody gets on the same line. Let me know if I'm wrong. So you're using a GitHub action to build and push to Docker hub on your repo name. So I should touch a 1912 something. Yes. The images for, yeah, for the main branch. Once they are pushed and now your Docker compose for just everybody will use these images instead of building the images on the end user computer. So we're not using Docker compose build but Docker compose and that's all. So it's downloading the already built images from your Docker hub repo. Right. And I think your question was what will be the repo, the Docker hub repo in the end? Is it repo the right name, the history, maybe or where we will store the images. If it's the question you had, I should watch. Yes. Yes. I understand the question. Hopefully, I think this is, this is a constant. Isn't that a constant? I think it has been defined in the GitHub action, but it hasn't been defined in the Docker compose. So can it be defined? I'm not sure if it can be defined in Docker as very even you. I think you could, but there the end user would have to have an environment variable defined somewhere, which is not really helpful. So I gave that for the time being we would have to use hot code in the value. Jean-Marc, what do you think? Would you have any other idea for that? No, my opinion, observation at this step was this is a constant and should be defined. Now, is it possible to define such a thing at the beginning of the compose? But in a compose, you can hard code it and put a comment on top is just to move the definition at a place where it is obvious. Now we can use that in the compose itself with a note saying this hard coded location because in the future we might use the Jenkins CI registry or repository. I think that was the right net, not repo. You were right. No, Docker hub is a registry. I think it's a repository. Repo, yeah. Docker hub is a registry because we could have used GitHub on registry, but we would have had the same problem. The prefix would have been yours. I should touch on others. Go ahead, Jean-Marc. I wanted to hear, but here I have one comment. Just leave it there. We should also document how to build the images oneself because I personally wouldn't trust images that are built by somebody else that I don't know, even if it's Ashutosh. Yeah, so I'm in a secure environment. Just as a note or so because I'd ask the question, we need the Isari people, what their opinion is and how we could do that. But we have a chicken and egg situation. If we want to push the images to a registry, we need credentials for that. Ashutosh doesn't have the organization credentials for Jenkins CI because we're still building the system. But then on the other side, we're using material where Ashutosh has the... So we need to trust at a certain point. Anyway, I'd be interested to hear Berbianto's opinion. I don't hear you. We can't hear you Berbianto, unfortunately. Hello. Yeah, I heard the word. I think it's fine for hard code, but yeah, I'm in the same page for the comment if the user want to build the image themselves. And yeah, from my side, usually I don't trust any image from what I don't know. Yeah, I get it. I'm on the other side because I rarely did production work, so I always try various Docker images, whatever they come from. Life is too short not to try unknown Docker images. Just kidding, but I totally get your point Jean-Marc. It would be way more serious to do that with somebody or an organization that you can trust. I'm not saying we can't trust Ashutosh, but of course people not knowing him, not knowing if his image is okay or not to use. Got it. But as you said, it's chicken or egg. We don't have the credentials to push our images to Jenkins CI. Yeah. I think that you're right also regarding the temporary solution, which is document everything so people know what they can do. Cool. Got it. I will create a work item regarding that later on. Got it. Should we start a discussion with SRE team in order to host our images in the Jenkins CI or is it way too early? My vote is too early. My vote is that currently we have many other points to finish. We made a note of it that is a potential problem. I prefer that Ashutosh finishes all the demos that we have something that we can really use, user or public facing, like the demo you did last week, which is a good example, that we focus on that to complete as much as possible so that at least it's usable. And then if we have time at the end, we can then work to make it production grade ready to publish it. This is my vote. I don't want to influence others. I have the same vote. Ashutosh? He didn't speak. I saw his head move. I saw that. It was okay. Sorry if that was not the case. But yes, I saw the head move before the lips. Thank you, I got it. So we're all okay with that. We'll still use your Docker Hub repo Ashutosh until we have time to do something which is more production grade. Don't forget to do it. By the way, yeah, it's important. Ashutosh, are you still using in the GitHub action that tests the Jenkins CI? Building the images locally, not downloading the already built images. You're building the GitHub action that tests the Jenkins CI images, right? Yes, yes. This is just a separate price. Okay, that's what I wanted to hear. Okay, so should I stop sharing? Thank you. Let me find the right bone to share my screen once again. Okay, you should be able to see it. We're at it before you move. Discussion topic is your demo internal demo here at Talby's to give a feedback about it. The one you prepared Ashutosh and you. So what do you remember that you do? Yeah, remember. Oh, I should do the feedback. Okay. Yes, I was there. Yeah, of course need to be now. That's as a discussion item. Oh, sorry. Okay. Thank you. You got the point. I think so. So that we don't forget. What's written. We won't forget. If we take the time to read it. Yes. So we have things adding if condition and put ID real jobs. Not tutorial URL. And multi branch pipeline. We haven't talked about this one, but it was more or less straightforward. I don't think you've got any trouble doing this one. No, this was more or less documentation. Yeah. Just moving from pipeline to multi branch pipeline. Yeah. And docker hub image. We also talked about that already. That went fine. And just before the meeting, I couldn't see any new PRs. In my right. Yeah, I think there's not. Okay. That's cool. So we still have 30 work items. So it's less than last week and even less than the week before. So we still have a big one, which is keep the plugin list up to date when building the docker images. So you may have seen a few PRs last week because we had some plugin releases. So I updated the list of plugins. More or less manually and make the. You did that. I run a script. Locally. So I don't know how you define manually. I didn't had a look at all the plugins and see if they were updated. I just was running as a main branch and I saw that the instance was asking for new plugins. So I updated the plugin in the instance and then I run a little bit of script that just compares the existing list of plugins in the running Jenkins instance with what is like in the plugins that takes the file, which is on the hot disk. And that gives me that tries to create a PR, but that did not work for me. So I had to put the updated plugin. TXT and put it by myself in a PR. So I had to do that. I think twice last week, which is not really interesting. It's mostly boring. So that's why I'd like to keep the plugin list up to date automatically while we are building the Docker image or not. We could do it at another time, but I thought as we are regularly building the Docker image, is it weekly, Ashdash? I think it's, I don't remember correctly. Okay. But it's regularly the first time being that should do. So I was thinking when we are building the Docker image, we could also fire up Jenkins and see which plugins should be updated or it could be at another time. Maybe when we are trying a new Docker file, you know, with Jenkins test Jenkins, you already have, or maybe we could create another GitHub action that runs on the databases, whatever. The thing is we have to have some kind of bash file that compare things to Jenkins plugin CLI. And that gets the updated list of plugins. And then maybe create a PR all by itself or do something. So we know we have something to update. But yes, a PR would be really the best. I already managed to do that, but it was not thanks to GitHub action. It's in a running Jenkins instance. I have on my machine and I have, I have a multi branch pipeline which scans for the plugins and do that kind of job. So I don't know how you should or would do that, but please investigate and see what we can do. The best of that would be an automatic PR. That would be cool. And that's one way to do it. But I think maybe update CLI can do it also. But frankly, understanding how update CLI works takes some time. So I don't know if it is worth the effort. Jean-Marc, what would be your feedback about this one? It's a tough one. I'd like to leave Marie-Vientoux speak, but I'm always... Marie-Vientoux, do you have an idea or a standpoint? I think we can try use GitHub action first before instance of Jenkins. Yep. Got it. I think you already have most of the bricks as you touch. You already know how to start a Jenkins instance within the GitHub action. So the first one is kind of easy. And then you would have to experiment on your local machine with the Jenkins plug-in CLI to know how to discuss with the Jenkins instance and get a complete list of existing plugins up to date. And then you'll see what you can do. My proposal was to create a PR thanks to the GH tool, which you may have on your machine, which should be part of GitHub action. I think it's installed by default, which also exists, I think, under our Gitpod environment. So you have a lot of different places where you could give it a try. You'll see. Would you have any question about this one? Do you see how you could start with this one? I think you already showed a mark, and you showed a script that does similar work similarly. Previously with checks there. Yes. It works more or less, but the script I have works within the Jenkins file. So it may not work the same way under GitHub action because you don't have the same variables available. The environment is not quite the same. So it may be a base to work on, but that won't be a direct copy and paste. I'm sure it won't work that way, but in some kind of a guide, if it can give you inspiration, that's cool. But I don't think it will do way more than that. Okay. Bruno and Ashutosh, my point of view on that is that this is a very interesting problem. If more urgent tasks are cleared, I would personally tackle that one before the one we discussed just before where we needed the SREs. We need to explore and understand or describe how to do that before and though it might be linked because some of the things could maybe only be done if we're running in a real environment. So at least doing R&D on the subject would be useful and interesting. Yes, we will all learn a lot of things, even if this doesn't work at the end of the week. That's for sure. It's an important one. I know that the paying version has tools for that. So the CloudBees CI solution has, in their implementation, enterprise-grade solutions for that. Got it. The thing is, if we are running that under GitHub Action, it would somehow, I think, simplify the workflow because GH is already integrated. All the variables to log you in the GitHub repo and so on, it's always available, I think. So you could do GH... What is it? GHPR creates something. It would be way easier to do that under GitHub Action than on your own machine. So that's maybe a track to follow. We'll see. But then generating the list of the plugins that are required. Can that be done with the command-line interface or how would you solve that? Maybe this is the subject of the R&D. I don't know. What I have already managed to do is to get the whole list of plugins, not only the one that you are interested in, the one that you put at the beginning in the plugin.txt, I just want, for example, the GraphView plugin and something like that. If you have, with a Jenkins plugin CLI, you've got the whole list, even the one that you didn't ask for, the one that were bundled with a default installation of Jenkins. So you have this whole list and up-to-date, thanks to the Jenkins plugin CLI tool. So you should have everything you need to get the PR, at least the pinned version that are up-to-date. I hope I answered your question and not something you didn't ask for. Can I make myself clear? Yeah, it looks very interesting. I only have a problem with what is the priority of that. So we need to handle that with care, because this can turn into a rabbit hole. But it's definitely exploration that needs to be done. Okay. Then we have a small one that could bring us some comfort, because it's kind of easy. It's a quick win, I think so. So the do-not-build-the-images-for-the-end-user-use-pre-build-images, I think you've done this one already, right? Yeah, I saw that a few minutes ago. Yeah, I haven't created the PI yet, but I think it's done. You did? Okay. So almost done. Yep, go ahead. Yeah, I was just saying I've committed the changes, but I haven't made the PI yet. Okay, that's fine. I pushed the changes, yes. Then the next one was about to remove the jcask proxy warning configuration, because, of course, we didn't manage in the previous week to get rid of this warning when using Gitpod. We don't understand what's going on with Gitpod. It does something with HTTPS headers and so on, and Jenkins doesn't know what to do, so it's giving us a warning. And it's important to let people know where they're not using Jenkins the correct way. So we don't want to remove that warning for each and every configuration. We only want to get rid of it for Gitpod. We are not proud of that. We documented that, but we have to do that. So have you started this one, Ashutosh? I've tried it by editing the Gitpod EML file. I think it worked. I will make the PI today. I have tried it a little bit and changed the... No, hurry. I just wanted to know if you had started, but that's not to say, ah, it has to be done today, not at all. Okay, you have already tried it. Yes. I think it will work. I think it should work fine. Okay, next one. The next one is dependent, but it's not configured yet. I can't figure it out. We did that together, I think it was last week or even the week before. You clicked on all the right buttons into the settings of the repo, but it's still telling me, no, it does not work. It's not configured yet, and I can't understand why. There already is a dependent.yml, so the config file exists, but dependent doesn't update our dependencies, which is a shame. The shame you may have seen last week that I made a few PRs in order to update various dependencies like the SSH agent version. What else? I can't remember. Maybe the bookworm version, yeah, also. So I would like... Are we having an error? Get an action. We don't have... I don't have an error. Could you... Do we have... What, sorry? An error. I should share maybe... No, we don't have an error, really. We just have some kind of gentle warning. It's green saying, hey, dependent.yml is not configured yet. And as it's a... Even if it's a public repo, we don't have the rights, Jean-Marc, Ashutosh or I, to do anything regarding dependent.yml. We don't have the settings menu on the right. We tried to change the rights of the permission. Ashutosh should have. Yeah. He has. But we don't... We did try to change it, but it was not working. I can't write it. I forgot where it's supposed to be. Security? Maybe you can't remember. Dependable. Yes. It is vulnerability. It's open to the new alerts there. I've done that years ago. I've done that on many repos, even a few weeks ago, and it works for me. Can you show me the code? Get it on my fork. And it works on your fork? Yeah. Oh, that must be a dumb mistake. No, no, no. Yes. And we clicked on the right button. I don't remember. I know how to do that. I just don't remember. I think it was in settings. Or even I may give the right link into the issue. No. Select settings. Settings. On the right. The tab. Higher. Move your mouse higher. On the right. Okay. Right. Yeah. Yeah. Yeah. Yeah. Security and analysis. Okay. Okay. There is. When you click on configure, you should open the dependable. Yeah. Okay. Yeah. There might be an error in there. Then you should have a. I can't see anything. No, no, no. And it's a very same file that works on my fork. So you're using the same file. Yeah. So and where you come back. Dependable security updates. That one is disabled. I think it was. Yeah. Oh, there when you click on it, you disable it. Okay. Yes. So it should work. Grumble, grumble, grumble. Would be convenient if we had that working. Yeah, it did. And I think it has never, ever run. If you go to GitHub action, it doesn't show us an available action, I guess. Yes. A lot of them are running, but not this one. It's obvious that we did not spot. But you do that. Yep. Okay, so let's. Yeah. I'm interested to have Bruno's feedback on the demo. Oh yeah. Okay, let's go then. But I don't know. I don't know what, what item you are on, on the list of. I think we're done. Always. Yep. The only thing that was left was the end to end multi branch pipeline project creation. And this one, we may need to discuss this along the week. Because I don't know if we will be able to make it without Docker in Docker. I haven't looked closely lately. So I don't know. I'd love to not use Docker in Docker. Frankly. It would be real reason to be proud of the whole project. If we can make it up to the end without Docker in Docker. Yeah. So we'll see. Once again, try to spend some time, make some proposal, give us some comments, and then we'll discuss in the issue and we'll see how we can solve this one. So as for the feedback about our internal demo last week, Natasha and I prepared a short video just before the internal demo, just in case I wouldn't be able to make the demo. And I linked that in a slide deck. And the whole meeting was recorded. And in the end, the recording stopped. And then I was asked to make the demo once the recording was stopped. So I can't share anything because it hasn't been recorded. But I think that it all went fine. We've been rehearsing with Ashutosh a few minutes before. So I almost knew what to say. And I think it went fine. We had some questions from Mark, which helped me having a better demo, I think. And unfortunately, we didn't get any question except for Mark. Jean-Marc, what was your feedback about this demo? Afterwards on the Slack channel, I've seen some positive reactions to what has been presented. And probably the people watched the video of the demo. So I've seen at least two or three positive comments. Yeah, I think people liked the demo and what was really, I hope, clear what the difference between the very, very long existing tutorial and the shorter one we are aiming for. And the thing that everything works with just one comment. That's beautiful. This is also what I've heard as a comment. So meaning that the work that Ashutosh has done and the team here has resonance. So we're on the right spot. Yeah. And I did not forget to say your name. Even if I don't pronounce it well, I didn't want to have all the glory on myself. It's your work with, of course, the three mentors. But yeah, that's real work we can be proud of. Thanks to everyone. Cool. It's already 18 by 4 in here. Anything else you would like to ask or comment before we wrap it up? I have. Go ahead, John. Yeah, so organization here. So I just want to be sure that Ashutosh knows what to do. Bruno is supposed to be on holiday. Monday, I'll be off this for sure next week. And Tuesday too. So that meaning Ashutosh will be flying solo for part of this week and the beginning of next week. Just want to check if everything's okay. If priorities are set and discussed. Just to check is everything. We haven't set the priorities. Yes. We know what Ashutosh should do, but we haven't said you should do that in this order. So I was thinking of doing the previous week's content first then this week's. Okay. Could you please say it again? I'm not sure I got it. Just saying that I was thinking I will do previous week's issues first then this week's. Okay. But you say John Markey would be flying solo, but I'm not so sure about that. I don't think. Yeah. I just wanted to say it now, but you're. Yeah, two of us won't be there. But they are going to be there. Sorry. All on your shoulders. You're in. Yeah. Okay. Good. I also wanted to know how for how long, you know, it's going to be on holiday. Two weeks starting today. Okay. And I'll be off. Yeah. Yeah. Next week. I wanted to say that I will have a look at the, or the issues and the shared document. I'll be there every day at night, my time. So yes, I'm on holiday, but I'm kind of there, but don't expect immediate answer. That's all. Okay. Good. I'll be a hundred percent off. Monday and Tuesday of next week. And in between I'm still catching up. With the project here so that can be helpful. They keep piling up things on my desk. In between. So yeah, so I'm. And as it is my boss who's piling it so I. Need to handle that before. I also, I also wanted to mention I might be. Traveling for two. Three hours tomorrow. I have to visit my uncle. He has some troubles with his health. It's not that big of a deal, but I might have to visit him. Tomorrow. It's not that far. It's only like. Three hours with. From here. It won't. Take much time, but just mentioning it. Okay. Yes. We're not expecting anything from you tomorrow. That's okay. No, no. I won't take that much time, but that's fine. I know, but it's easier for us to say don't expect anything. And if anything comes, that's a bonus. Don't train too much. You will be on the road on the train and. Dealing with not that funny thing. So yeah. I'm going to do my nasty. Yeah, go ahead. I'm going to make my nasty matter right now. Do we have a clear idea what we want to have in the delivery. Of end of this month. And make sure that we're working on the right stuff. I was thinking. When we will be. From that have actions to. Main Jenkins. And that should. That'd be. I was thinking that should be included in this month itself. Well, I don't know between what and what we have to choose. Because. We will depend on other people. So. I'm reluctant to include that in the delivery of. End. August. They currently struggling for the list. Sorry, they're struggling with a bandwidth issue. On the Jenkins. Artifact repository. And this costs a lot of money. This is where their priority is. So. Yep. What would be your. Inside. To. Add that. During the wrap up phase and see what can be done at least document. What needs to be done. And I should touch could maybe. Do that. As a follow up. For the. The Google summer of code project. So there is the Google summer of code official delivery. And then there are contributions that he could do. Once a project is completed. So this is my proposal. And so we can decouple. The things. What do you think of that? Fine with me. What would be your. Expectation for the delivery at the end of August. Do we have all. Tutorials done. The multivariate pipeline. Still. This one is heavily. Based on. What is it? You know the deprecated. Ablution. I don't know how. Yeah. I don't know how to translate with a grab you plugin. It may not be. Good enough. For replicating exactly the tutorial we'll see. I haven't tried it yet. And I know there are lots of other tutorials. Around the Jenkins IO website, but I don't know. If we could rewrite them. Thanks to our project. I have to see. A good way to branch. Yeah. The good way to check is to see with a doc. SIG. And ask them, could they already start something with that? I think two important features. Required. So one is that. We have a good procedure to update the plugins. So that when people start the demo that they don't get warnings. On their. The systems. And the second one is that we. Are. Running on Jenkins. On, on the. Jenkins CI Jenkins system. Now. So this is the realization problem. Yeah. But I said, I want to decouple these two points. From the delivery of Google summer of code. It would be stretch goals or. Things at least we need to document and think about them and say, well, this is the way we can handle that. I see. Because even. If you just want to change documentation, the thing is you would have to refer to. Repo. And it's not official. It's not part of Jenkins. So that could be a firm, you know, if I wanted tomorrow to rewrite the tutorial about Maven. Is it something that would look cool to have. Repo. Why I should touch. You know, it should be Jenkins something to be part of the whole Jenkins ecosystem. And we can't do that. Yeah. Yeah. Yeah. So I don't know where to start. It's worth to ask the documentation SIG. What are the conditions for them to update the main documentation. To include. Ashutosh. Bowling. I did ask Mark about this. And he said to. He expects me to make a PR. Yeah. Which is a good start. Yeah. Which is, which is a good start to. Start the conversation. Yep. You're right. Which is maybe for Maven tutorial, for example. Yeah. Yeah. A few weeks ago, I made a PR that was more. A discussion than anything. Because I wanted to change something for Jenkins. And it took lots of weeks before anything got merged. It was more to gather. The feedback from the community. Would that be a good idea? How would you do that? Why wouldn't you do it this way? And I think such a kind of PR. It could be helpful for us to progress. To get out of this chicken or egg and or egg. Situation. Yes. I think this, this would be a nice way to wrap up. The project. So. That we, we can. So I should touch could propose. This is the way to integrate my work. Into the main site. And say what these two points need to be addressed. But. So the one is the upgrade of plugins. The other one is to integrate that in the CI infrastructure. Of Jenkins. Are there other things. That need to be done. This is my proposal. This, this would be a very nice wrap up. I think so. And we could even create some PRs for. Not PRs issues for Jenkins. Not PRs. I think so. And we could even create some PRs for not, not PRs issues for Jenkins. And prepare them for act of a fest. And then you could come back in October. And saw them. And win a T-shirt. And you would get a free T-shirt. Yeah. Or plant a tree. Yes. Yeah. No, I think this is a nice way to do. But we're, we're, I think we're. If I get it correctly, we're, we're done with implementing the tutorials or we have enough material to have something to. All the others are blue ocean bound. Yeah, I think so. And even the multi branch pipeline tutorial is full of blue ocean. So I don't know. I hope that we will be able to do it with a grab you pipeline plugin. And without Docker and Docker. And if that's not the case. And maybe we should not do this one. Yeah. Yeah. Great. Thank you. But until I haven't heard what you think the. End of months target should be. You. About. We need to start integrate. With. Yeah. Cool. Thank you. Integrate with Jenkins.io. That's nice. So I won't be able to make it to the Jenkins docs office hour this week. I don't know if I should touch you will be able to do this one from Friday. You feel like you. Yeah. Okay. I should be able to make you can start. The discussion with Mark and Meg. To see what they have to say about that maybe we'll have then a better view of what should be the roadmap. Okay. Thanks a lot. John Mark. Do you have anything else to do? You know, playing the role of the nasty mentor. No, I, I, I see it crystallize. So I'm, I'm happy to, to see the results. I'm. I think we're, we're getting there. But there's still a lot of work to do. And. Oh yeah. And, and this is post cheese. So this is an encouragement for shoot us not to disappear in, in space. All the work you did, you're the best one. To continue to promote. And to make it grow. Maybe not directly under the GSOC banner, but then as a Jenkins contributor. Would be nice. Yes, indeed. Yeah. Integrating. Okay. The Jenkins CI is a great, great. Host GSOC. Graduation. Yeah. That would be a great outcome of all that. Yeah. Yes, indeed. I'd never. Anything that big to great. Yeah. Yeah. Yeah. Yes, indeed. I'd never. Anything that big to great it into the Jenkins ecosystem. So I would really be proud if you could make it. That would be. So. I think we can wrap it up. It's already been more than an hour. Yes. Thanks a lot for your time. The video should be available from 24 to 48. And I'll add it to the community Jenkins IO. Post. Great. Now Bruno back to gardening and holiday. Yes. Just time to grab a coffee and then I'll be back in the garden. Thanks a lot. Thank you folks. See you soon. Bye bye. Okay. Bye bye.