 to the cloud. Done. Hello everyone. We are on the 28th of August 2023. And it's GSOC Jenkins Docker base quick start weekly meeting. It's the last official one as we are reaching the end of the GSOC 2023. We haven't asked for any extensions. So this week is the final week. And we will have as mentors, so Bea Viento, Jean-Marc and myself have to begin the evaluation of Ashutosh before September 4. And it's starting tonight my time at 8pm. So be afraid Ashutosh, be very afraid. That should go fine. We have another deadline, which is important. It's the 14th of September when you will have to give a presentation, a 10-minute presentation and five minutes for questions about the whole work you did for the GSOC project. And this morning I had another talk with Damian DuPoto from the infra team because as you know it we have a chicken and egg problem. We can't have PRs merged into Jenkins IO as long as we don't have our images in the Jenkins CI or Jenkins infra organization. So he asked us to open a ticket on the infra help desk to start the beginning of the discussion about where should the repo be integrated, should it be Jenkins CI or Jenkins infra with this, because that in a few minutes from now. So last meeting Ashutosh, we were okay with you beginning the presentation at the beginning of September. We were not in a hurry. That's still valid for me. What about you? It's fine with you. So from next week I would say beginning of next week. Yes. That's cool. And you already have some material from the midterm presentation. So that should go fine. Regarding the extension. So we didn't ask for any extension because we are more or less done with what we had in mind. And what we'd like is to bring this project to Hacktoberfest and to be part of Hacktoberfest, we would like, we will have to have it integrated into Jenkins CI or Jenkins infra. We are not an open source community yet. It's just the four of us. So that does not work for Hacktoberfest. That's why I'd like us to focus on having your work integrated into Jenkins IO and Jenkins CI or infra before Hacktoberfest so that we can tag along the month of September, good first issue, Hacktoberfest and so on if people would like to participate. So the discussion I had with Damian this morning was about should it be into Jenkins CI organization or Jenkins infra. As you already know, Jenkins IO is in Jenkins infra. And that's because it's run on Jenkins infrastructure. So that's why it's there. As for Jenkins CI, most of the projects which lie into the Jenkins CI GitHub organization are things that will run in the end on the end user machines. And that's a rule that we have. And this project is in the middle of the bridge, I would say, because some parts of this project will finish into Jenkins IO. So it's part of infra. But some parts of that will run on the end users machines because they will run Docker compose with our images. So I think we have to discuss that. And the first step is just to declare a ticket on Jenkins infra support. That's not an easy one, but that's okay. So the first thing to do will be in September. I don't know when, but in September, have your repo or fork of your repo, maybe a stripped down version of the repo without documentation. We'll see something maybe much more concise, maybe cleaner. I mean, with not that many rhythmifies and so on. We'll see something more concise into Jenkins CI. Maybe we'll see. As for the pull request we had last week, I saw six plugin update PRs. So your work works beautifully. It's a good thing to see and plugins are updated regularly. That's a lot of work that we don't have to do manually. And that's a good thing. We also have seen nine depend about updates. So this has proved that it works, which is pretty cool. I've seen some version updates today on the agents. You know, the agent image Docker agent images. So hopefully within the week, we should have some new dependable updates, because I think it's round weekly. Now, as for the open PRs, there is a big one, the end to end multi branch. And could you give us a status on this PR, please? Yes. So the tutorial was more or less complete, but I was getting another error while checking for the tutorials from the GitHub actions. The main GitHub action files that test the running container and checks if the job is running that was giving error. I looked into it and the error was coming because the conflict dot XML file and that creates the job, but not being accepted into the Jenkins for some reason, it was being created, but it was not showing as the job. So for that, I I searched a little bit and found out that we can curl and create a new job with curl command too. So for that, I have the XML file is still there, but we are not transferring it directly into the container with we are transferring it after the containers are created with the curl command now. And it's working now. That's cool. Well done. So it could be reviewed and merged this week, hopefully. I think, but we want to review it a little bit. He asked a question I replied. Okay. And then weekend came. So that's cool. I think he replied on weekend. I haven't seen that. It was about because right now, we are using images with the branch name right now, because it's in separate branch that we need to remove when we merge it and remain too big. It's too big. Well, okay, we need to have the merge in which is right. Now should I remove it? I guess so, yeah, but we're almost good to go. That's cool. Now there is a conversation going on. It's about the layout of the documentation. So you asked the question as we asked you to do last week. So yeah, should we keep the same set of Docker campus files? Should we do another one for the second persona or not? And I gave my insight on that and Bavian to also. So I don't know what you think about that, but we may go with a smaller file for the second persona, which could be done automatically or by hand for the time being. I don't know. I tried it by doing it by hand and it worked fine. It was not that complicated. Yeah, please. And we just have to think of keeping them up to date. Yeah, okay. We need to use them as files. Okay, I didn't think about that. I was thinking something like this, like we will give the git clone command, which will lead to our repository, which will contain all the tutorials and users can just do this and skip this part. But second part with the files, this is for the first persona. But if someone wants to do it manually, like second persona, they can, this is just for the main part because I've removed all the other services and it works with the same command, doc composer, Maven. And I have edited the new images, I'm sure. This one is too big. I edited it, but I was thinking like this. What do you guys think? I don't know. I think it's maybe too much information for the first persona. It's very nice to have it there, but it's maybe too much. What do you think, Jean-Marc? First site, it also looks very busy. Looks very busy. The question is, what could be simplified? Yes, all should we create another documentation elsewhere? The channel is, if you want to know more additional information. Could you please, yeah, go ahead. The additional information, like should we do it, like just the link here for the first persona and if second persona wants to use it, you can get to somewhere else, like GitHub read me or something like that. I think it would be better. Yeah, we can add instructions for building images and all that. Yeah, I think so. Okay, so like here only we'll give the link for the GitHub list and then we'll continue from here. I would prefer that if you don't mind. So for like, for making the PR for an event tutorial, all we need to do is remove some stuff. So like, where should we add the documentation like right now? GitHub read me or because right now read me file is not that verbose. Yeah, I got it. Maybe you should create another file next to this one, but it should also be part of Jenkins.io in the end. So I don't know how you could articulate that, but maybe you have between some somehow of this for the second persona, but I don't think it's placed in the readme.md. I think it should be part of the official documentation also in a way or another. So we shouldn't lose it. We have to have it somewhere, but I'm not so sure readme.md is the right place for it to be. Mm-hmm. Great. Jenkins.io used a lot of the direction too. Mm-hmm. Maybe you can, there are a lot of different files. I was getting confused with them when I was trying to do this too. I think some more can be there too. But how will we, we'll be keeping them updated so they... That's a question. With ASCII.doc, you can have some include files. Yes. You know, if you want to reference a code file somewhere, instead of copy paste into the document, you can do it via an include instruction. So that's maybe what we should do. Oh, sorry. Somebody is ringing at the door. I'll be right back. John-Marc, please go ahead. Well, I a little bit lost the... I prefer that we pause the recording. We'll pick up again when Bruno comes back. Is that okay for you? It's okay. So we are back. Thank you, John-Marc. So we were discussing should we create a twin file on some sort in order to have the official documentation for the first persona and a more detailed one for the second persona. And we were also discussing that we can include some source code files within the ASCII.doc. So maybe that's the solution we should be aiming for. You know, keep the Docker files up to date on their own and then include them in the ASCII.doc files. But we have to be very careful about keeping the files up to date nonetheless because the files that we will include are not the main files we are working on. The main files are the Docker compose that are kept up up to date things to depend about. But we have to make an excerpt of them and then create those small files for the second persona. And that's where we have to be very careful. I would love to have an automatic way of doing that instead of relying on our brains. I don't know how to do that, frankly, for the time being. We could maybe use something like YQ because it's YML. That could work, but I'm not so sure about that. Never tried that. So YQ is a YAML parser and that we already use a little bit in the GitHub actions, I think, and for Github in order to find the right endpoint, I would say. Does it work on volumes too? Volumes? I think that should be the issue. Yeah, it should work. Hopefully, yes. I will try it today. My son is not working anymore. There are days like that. Yeah, should stay in bed these days. Do you manage? Screen is off. Yeah, his problem is he is the meeting organizer. If he drops out, the meeting dies. Yes. And I don't know how to reclaim that. I had the opportunity once, reclaim host, there I am. I got the message that you have now. Going to post the recording. Yeah, thanks a lot. Zoom crashed. Can you see my screen, by the way? Yes. Okay, thank you. So regarding the layout of the documentation, do you know what to do next, Ashutosh? Yes, I think I got that. I will be experimenting with YQ today. So I'll let you guys know how it turns out. Okay, thank you. YQ and source code includes within ASCII. Nice. And then we'll see if we can open the first PR on Jenkins.io. Even if we know it won't be merged until a few weeks from now. Thank you. Now, regarding the tutorial about end-to-end multi-branch pipeline project creation, so we're almost ready to merge. You still have a few things to do, but I think that by the end of the week, we should be able to merge it. You managed to get rid of the issues you were having with the jobs in the test. So that's fine. We still have one which is not mandatory, which was used dependabot and update CLI to keep the samples up-to-date. As for dependabot, it's working. I think it's working. We have seen quite a few PRs, but we will have to keep it up-to-date because you added another directory for the very last example. So I think you should add a section about that into the existing dependabot file. And as for update CLI, frankly, I'm not so sure we will have the time to experiment with it. And to be honest, dependabot already makes almost all the work we need it to do. I was pushing a few weeks from now for update CLI because we did not manage to get it to work. And so update CLI was a nice replacement for dependabot. But now that dependabot works, well, let's keep it working this way. And maybe later on we could have update CLI for more touchy parts that dependabot can't handle. We'll see. So no hurry on this one, not mandatory. And I added another one minutes before the meeting, thinking of usual mark. I wrote move test from shell to goss. I haven't described it properly. I just get three links and that's all. But goss is a project written in Go that Jane Keane's infra already uses. So the whole thing you're doing as you know with curl and so on in a big bash file can be simplified with this tool which is called goss. So I don't know what it stands for. The first part Go is because it's written in Go, I guess. But it has a few advantages. It works on Windows, Linux, macOS. It can work with Docker compose. It's well written, I would say. Documentation is pretty well done. And yeah, I'd like that we try this one in order to simplify the existing GitHub actions. Your GitHub actions work beautifully. But frankly, six months from now, if I have to make modification in those files, I will have a hard time. Really, not because you wrote it badly. It's just because it's a bunch of shell commands. Yeah, it does a job. But frankly, maybe we tweaked things a little bit too far. And yes, it works. But we could have a framework to help us do that. So it could be goss. It could be bats. But frankly, I told with people using bats and goss, and they do prefer goss. So we don't have to do that. But maybe we should experiment just to see if we can get it to work easily. And if that could help us have something that is more maintainable six months from now. So I thought of you, Jean-Marc, because I know you're curious. Just looking at it. Yeah, just looking at the page here. Yeah. And for the Jenkins slow and Jenkins fast, there are already working examples. Fast and slow is because on some architectures, you will have Jenkins starting very fast. So you don't have that many steps, you know, wait for that and wait for that and wait for that. And on machines that are pretty slow, you have to be to have a few more steps, I guess, in order to wait for the several parts of Jenkins starting. Any help? That's just my idea. Yeah, I'm not seeing the right thing here. So I don't know if it's a standalone tool. It's something to include how to start. No, it's a standalone tool. You can install it within your Docker images if you want to test directly via Docker, or you can install it on your machine and test whatever you want on the machine you are running the things on. It could be a real service. It could be a service running through Docker. Do you have the reference to it? Because my Google foo doesn't give a good result. Oh, you mean the repo? Yeah, the repo or where the tool is located so it can have... Sorry, it's on GitHub. I'll send you the link via the chat if you don't mind. Yep. Let me find the right window. Can you see it? Oh, G-O-S-S. Goss, my bad. How would you prudence that? I have no idea. I made it French like Goss, which means child, by the way, in French. Well, I wrote it with a single S. So, Goss Orc, yeah, that looks much more... Oops, I need to check the time. There it is, yeah. Well, have a look to it. Thank you. Yeah, so I don't want to force push. I would just say that maybe we should experiment with that and see if it helps us having something more maintainable and more easy to write. It would be good to write now for the latest issue. I was editing that file and it is hard to read, even though I created it. So, yeah. Only thing that bothers me is that it relies on YAML once more. John Mark, you are about to say... No, looking at it. And so, this is a recommended replacement for bats? At least from the Jenkins infrared team, that's where I heard that, because they were thinking of getting rid of bats wherever they can and replace that with Goss. Yeah, the problem is with bats is that you need to be good at bash programming. Yes. And for Goss, you have to be good at YAML indentation. But most of the time, our IDE help us with YAML indentation. So, we're almost safe. And there are already processes running for the infrared team thanks to Goss. So, we can hope that it's a sturdy enough tool for us to use it. Yeah. Good. I learned something. Yeah, I never heard before this morning of this tool. So, Damian Dupoldo, if you'll read us. Thank you. And we're at the end of the agenda I had. John Mark, while you were away, I think I talked about the presentation that will have to be done by September the 14th. Is there anything you would like to insist on before we wrap it up? First recommendation is to be on time. So, not going over the budget. So, 10 minutes for questions and also for presentation and questions. So, the questions will be the adjustment variable. I am also interested. Maybe one or two minutes. And a couple of bullet points is what did you learn and what do you wish to tell the people that want to be part of GSOC for next year? So, in trying to make one single advice to have a successful candidature, but also a successful GSOC. Now, focus is something I will say. It had been a long time since the last time you say focus, focus, focus. Yeah. Does that help, Ashutosh? Thank you, John Mark. Ashutosh, anything you'd like to share? Or would you have a question, doubts or? No, that's it. I think to John Mark, maybe John Mark was not there. I will not be available for like three days, two or three days, because there is a festival here. So, yeah, and I will be traveling. Yeah. Okay. I heard that you were explaining when I joined the meeting, you were explaining what the festival was about. At least I understood that it was a festival, so it's no need to re-explain. I will do my homework there and knew that you were going to be offline or very difficult to reach for three days. Yeah. Go ahead. Normally for Ashutosh now, in four hours, he's done. Yeah. You didn't hear that, Ashutosh. You see, I have three weeks to go. No, no, just kidding. But yes, we are supposed, John Mark, to evaluate your work by, no, not by tonight, from tonight, 8 p.m. our time. And we have until the fourth of September, I think, to evaluate. John Mark, would you like to set up, that we set up a meeting to discuss that with Belvianto or you, or do you want that we do that asynchronously? Oh, I fear I will have a busy time. So, asynchronously. Okay. No problem with me. Here, trying to do it sync, the problem is I don't want to influence Belvianto. Yeah. Yeah. And here, started asynchronously. And if there is a tie or there are arguments that we need to discuss, let's make it together. Okay. Got it. Thank you, John Mark. Let's do it this way. We can discuss it tomorrow morning. Why not? Let's do that, of course. Thank you. You will be available standard time, like every week, because you're back home tomorrow morning? Tomorrow morning, normally, it should be available at standard time. Now, I found the house in because of the long absence, and I need to get a handyman here quickly. Oh, yeah, got it. So, we'll discuss that tomorrow. And no problem if you have to change the time slot. That's fine with me. You know my agenda. That's okay. Ashutosh, best of luck for the rest of the work this week. Enjoy the festival and see you whenever you feel like it, because no mandatory meeting anymore. But we could keep this time slot. If you ever want to, we can keep it for a few weeks or whatever, or if we all the week, we'll discuss that maybe on matrix element, whatever, as you feel. Okay. Ashutosh, you wanted to say something? I was saying that I will be on the Docs Office hours and Docs Office hours. Despite the festival? No, the festival. When is the festival? The festival is on 30th. So I should be able to make it on Thursday, 31, because it's a night for me. Okay. Unless you have eaten too much. I'll let you guys know. Okay, great. Enjoy the festival. Yeah, and thanks a lot for your help. Zoom related, Jean-Marc. I was lost today. Thanks a bunch, folks, and see you when I see you. Bye-bye. Okay, need to drop too. Yeah, bye-bye.