 Hello everyone, this is the GSOC Jenkins Dockerbase Quick Start meeting. We are on the 14th of August 2023 and today we have Ashutosh with us and Berviento, who may have some internet problems. So we are on the week 23, I guess, and we have lots of things left to do but quite a few things have been done or are about to be done. So what I had from last week was about keeping a list of the plugins up to date thanks to a GitHub action or something. We also wanted to give the users... We wanted that the users use pre-built images and not build on their machines anymore for two main reasons, which are speed and tested platform. We only want people to use our images on tested platform because we wouldn't want people to be disappointed after trying to build images on their own machines. And we also had a proxy warning configuration to remove only for GitHub, which was not working. Let's start, if you don't mind. So as for the node tutorial, we used to have a problem with the port 3000, which was hard coding the pipeline, but I think you have already sorted this out. Ashutosh, am I right? Yes, yes. I think it was sorted a week before. Yeah. Me too. Last week. And as for automation, there was another work item, which was about using the real job and not only the simple job, and I don't know what you did for... I can't remember what you did for the node tutorial in regards to the automation part. Oh, I think you did it. You added an ID to the input so that you could, with a call command, say abort or proceed. Yeah, you did it. Done also. So the pull request I've seen closed last week were browser to preview. Come on, come on. Looks like my internet is slow also today. Let me make it a little bit bigger. Ouch. Okay, thank you. So I had added a configuration for Gitpod a few weeks ago, but sometimes it worked. Sometimes it didn't work, and we didn't know why. And you found a workaround, which is the use of open preview instead of open browser, and it seems to work, at least for me and for you. I don't know if you have tested that, but it seems to work, which is pretty handy. That's why, yeah, cool. That's why it got moved last week. Well done on this one. This will prove useful because people won't have to click anywhere. It will just open the tab. At home, it's a tab. Is it a tab also for you or a new window? It's like half a window inside the code editor itself, but it has the button to make it full screen in another tab. Right alongside it. Then there was another one. I really wanted this one to get done is update Jenkins plugins because I was getting bored with doing that by hand. So the goal there was to find a way to update the plugin automatically. So the one I just clicked on is not the one I was referring to. This is one of the manual PR that I did to update the list of plugins, which is not what we are looking for. More on that a few minutes from now. Then we had use prebuilt images instead of building them locally. So the week before you had produced a PR that creates Docker images and push them to Docker hub. Okay, there it is. Oh, okay. That's for the next, my bad. Let's go back to prebuilt images. So now that we build and push images to Docker hub, we want the end user to use them instead of building on their own machine. So you did this one use prebuilt images instead of building them locally and seems to work so well done. And thanks for the review. Today we still have a few open PRs. So the first one is very old for Docker hub repository until last week we had hard coded in the, what is it? GitHub action. The name of your repo within the Docker hub registry. Yeah, that's a correct name. And so now I guess you have declared a new system variable. How is it called in GitHub? I've added the environment period. I think it's environment. So that now I've seen that you can use the variable directly and it will build and push to your repo, which is defined within the variable. Come on, come on. Yep. So Docker hub username and it's defined somewhere within the settings of the website of the other repo. There is an environment variable defined, which is called Docker username. Fine. So I guess this one is ready to merge. Yes, it's working for me. Right. Now I checked it. I haven't checked on that part, but it should work. Okay. Fine with me. The goal there is one day to migrate your repo to the Jenkins CI organization and just have to change one variable and we will be good to go. Then there's another one which is adding an updating read me. I think it's about the second persona and I could be wrong, but I think it is. Yeah, that's it. So as I've said a few minutes ago, we want the end user to use pre-built images and not build them by themselves. But the thing is if we have an end user that wants to know more about Docker and Jenkins who also may have a platform which hasn't been tested yet, for example, ARM 32-bit or RISC-5, PPC-64LE, whatever, we don't want to restrict these users. So we wanted to have a part of the read me that would explain how to build and execute the images built locally. And I think I gave a review earlier. You made the changes I had asked for, I think. Yep. So I think we are ready to go. Then we have this one which is not ready at all. I've read the summary of the last Docks Office Hour you will participate in. And you had an interesting, at least to me, discussion with Mark and maybe Meg, I can't remember, about this last tutorial. And it looks like we can't get rid of the Blue Ocean set of plugins yet to go to the end of these tutorials. So you put them back into the plugins.txt. You are right. Yes, for this tutorial, since it uses Blue Ocean too much, I've added the Blue Ocean to the plugin.txt list. Yes, I'm afraid we have to. But it works without Docker and Docker since it's similar to the Node tutorial, so using the same agent works fine. Yes, I read that. And that was a good surprise for me because I was afraid we would have to use Docker and Docker. So yes, that's cool. We went up to the end of this set of tutorials without Docker and Docker, which is a good thing. So not ready to merge. I think we will still have to discuss and maybe also with the next Docks Office Hours. We'll see. We should maybe make another demo show them that it's working without Docker and Docker and see if they find what they were expecting. But that's cool. We are progressing. Thank you. Ah, the one I was looking for, the plugin up to date. As I told earlier, I'm kind of bored with that. I don't want to do the plugin updates by hand anymore. I have supplied a few bits and bobs, you know, some hints to get you started. But I think you did something much better. And frankly, I haven't seen PR yet created by that maybe because it's not on the main branch. I don't know. Yes, I forgot to change the time to check, but it should create this tonight at midnight because I've used it. So it works on every branch and with different name for the branch. It uses the time, date and time for the branch. So I believe you, of course. But better safe than sorry. It should work without being merged, right? Yes. So I don't know which midnight is it. Is it the US midnight UTC something? Thinking lit. I should, it will be okay if I push it right now to check if it's working or not. Wait a second. Yeah. Go ahead. So would you like to share your screen or? Okay. Sorry. I'll share it. It's almost an excess thing. Live coding. That's cool. It looks like you are way more fluent with Git than a few weeks ago. That's a nice thing to see. Yeah. I want to learn GH now. I haven't used it much before. I used Mark in the meeting using it and it looks way better to use that. Mark is mastering GH and Git like nobody else. Yes, it's a joy to see him operating Git and GH. Wow. That's quite something. And it's a powerful tool Git and GH on top of it. It's a joy to use. I made some really cool things thanks to GH in Git of action, for example, or even in Jenkins 5. That's a nice tool. I love it. So we have something running. So Kodasi, we don't care. Okay, image, plugin to date. Oh, plugins, update, file, test. Failed. Oh. Okay. Okay. I think I did something stupid. The demo gods were not with us today. So we'll let you work some more on this one. Yeah. Wait a second. I just think it will work. Okay. Go ahead. If you feel like the small modification could make it. Fingers crossed. See the steam. What is it too small? No, no. For me, it's okay. Read it. Layers. Layers. Layers. Okay. So the agent has started. What about Jenkins itself? Jenkins is ready. Last LTS. Fine. Yes. See, sometimes happen. So origin main is not a commit and a branch cannot be created from it. Okay. So there is still some work to do. Sorry about that. Yeah. Stop saying this thing. Yeah. That's okay. Let me share mine. Nice try anyhow. So the last one was removing reverse proxy warning on it. But I've seen you've done something with YQ. I think. Yes. I have updated the report. Yes. You are. Yep. So I think it's ready to merge. Now we still have 14 items, not all of them are for last week, this week and next week. So we'll focus only on the ones for this milestone and the previous one. Yeah. So keep the plugin list up to date when building the Docker image. So it will not happen when building the Docker image. We all got that. It's every day at midnight. And it will work in a day or two. Yeah. The next one, we've already merged this one. Oh, we haven't figured out yet how to configure correctly, depend about. Because I haven't seen any PR for depend about yet. I guess it's not working yet for whatever reason. I know last week we clicked on several links, buttons, whatever it did not do anything. And I guess nothing has changed on your side. No, not yet. Okay. But I would really want to see if this one done because it will keep the project way more secure, I would say. I may be naive thinking it's just updating dependencies will make it more secure, but you get the idea. And frankly, that's something that don't want to do by hand anymore. We have tools to do that. So let's try to make it work. Then we have the end to end multi branch pipeline project creation. So you've discussed that with Morgan mega thing last week. Would you have anything to share regarding that. So, Mark was also agreeing that we should keep blue ocean for at least one of the tutorial. Since it's easy to understand for beginners to and also when I first use Jenkins, I used it with blue ocean. So I like blue ocean. And I first used it was simple to understand. Yeah, it's a very nice tool. The only problem is that it's deprecated or about to be deprecated and that's why it's a problem but if Mark and make agree that we should use it and go for it. Sorry, I interrupted you what were you about to say. Yes, so other than this. That will don't don't need docker and docker for this. And so, yes, I had another issue while creating the PR for this. And it's documentation it says that it has to use multi branch pipeline so in one of the pipeline. It should create. Output in port 5,000 but instead it's creating that in port 3,000 instead. So like there are two tutorials, two things, two times when it creates a react website output one on port 3,000 and one on port 5,000 according to the documentation but it's creating both on 3000 for some reason. I don't know in the tutorial. It's something the wrong with tutorial and I don't know right now. I don't know either. I will have a look. I don't know I can't remember and it's kind of complex the way they start with docker and so on so maybe there is a definition of the port 5,000 somewhere. I don't know. We'll find out. I am trying to find out right now. I'll let you know if I find out anything other than that. I asked Mark how should we how it will go by integrating this into Jenkins. So he said he wants to wants us to me to create. PRs on the Jenkins.io separately for each tutorial. But I'm not sure how it will go that first maybe first we'll need to be touching with the infra team to discuss. It should be first go with the documentation. Okay, so only documentation for the time being. Yes, and I also wanted to know like like you mentioned before like it's not production ready yet and how it can get production ready or what we need to do for that. That's a good question. To be honest, I don't know yet how we should do that. We've got lots of security alerts that maybe we should get rid of before calling that production ready. You know of the alerts we have in the security tab in your GitHub repo. We have to have the automation of the Jenkins plugin update. We have to have the automation of the update of the Dockerfiles. All of this has to be automated before even trying to call that production ready. And then I guess we should have a discussion with Damian de Porto and the other people from the infra team to know what they are expecting before integrating that into the Jenkins.io organization. Frankly calling that production ready as it's only a tutorial for end users is a bit stretchy. So yes, I guess the thing we should do we have a clear discussion with people from the infra team to know what are their expectations. What are the prerequisites? What do we need to have something that they could integrate into their infra? Okay, I got it. First of all, let's do documentation PRs. What bothers me with that is, okay, we'll modify the documentation, but we should modify the documentation while referring to your own GitHub repo. Yes, that's that's what I'm going to do. Yes, it's a chicken and egg problem. Yeah, I won't be able to make it to dox office hours this week. So I don't know if you will be able to go into one of them, but maybe you could ask questions to mark and whoever will be there. So we know how we should start. Should we start with the egg or with the hand chicken to the existing repo? Whatever, I think I have this play problem and the requirements. I never clicked on the O but there is no whatever. Okay, anything else about this last dox office hours of this tutorial? I don't think this is it. Okay, do you have anything, any feedback? Okay, thank you. Yep, whatever. Okay, so we still have more than two weeks to go before the end of the month. Yes, we're only on the 15th tomorrow. I was trying to think straight in my head, being in PTO is not easy. You know, I even don't know which day we are. Of course, we are on the 14th today. Need to sleep, whatever. So I don't know when you are supposed to be done with that project at the end of August. I think because we have to make an evaluation for the beginning of September, am I right? According to the GSOP timeline, coding period ends at 28th of August. After that, it's mentors evaluation. So I think what Jean-Marc said last week is still valid, relevant. So we'd like to have a document that tells us what needs to be done to be part of Jenkins CI. So you've already gone to last dox office hours. We know more now because Marc said he wanted to have some PRs for the documentation, but we still don't know if we should refer to the existing Ashutosh repo. So maybe you should write down somewhere that we still have some questions. Then we should have a discussion with the infra team knowing what are their prerequisites and expectations. So all of that should be documented because we may not have enough time to be part of the Jenkins CI organization by the end of the GSOP project. So at least let's document that. This one can be more or less removed. Yeah. Okay. So yeah, definitely that's what we should focus on once we have finished the technical part. We don't have that many work items left. Some of them could take quite a lot of time we'll see, but it would be nice to have them done by the 28th of August and then have a document that lists the things that we'll have to do later on to be part of the Jenkins CI organization. Of course, it's your repo. Maybe you'll find sometimes you're in there after GSOC to continue working on it just tiny little bit. Of course, not 20 hours a week. I'd like you to be there when it will be part of the Jenkins CI organization and see that your documentation is in Jenkins IO website. I think that would be a freaking nice milestone project done. Yeah, I contributed. It does work. And of course, we would like to keep you as a contributor or regular contributor for Jenkins, but you don't have to. We would love to have you after GSOC ends. And we've got to ask you guys another thing like for the next year or a year after that I'd like to become a mentor like you guys are. So, like, like, not you guys, like you are to experience like, like some of the like he contributed one year, then he became the mentor next year. Chris did that. Yeah. Yes. And so how, how much knowledge do you think I would need to become a mentor? Should I next year should I again participate as contributor then become a mentor? That's a tough question. Frankly, I don't think I know that much, but I became a mentor nonetheless. I think it's not knowledge. It's more about experience and maybe confidence. But even if you don't know, you know that if you search, you will find out or you will find somebody that who knows what it's all about things like that. It's not about global knowledge. Frankly, I don't know that much. And that, but that was enough to become a mentor. But I won't evaluate myself. I won't say I'm a good mentor. The level of knowledge I have, the level of experience I have does not make me a good mentor. I have no idea. Bevin too. What do you think? No, no, I was not asking for your approval. Not at all. Not that. I wanted to know what do you think is needed to become a mentor? Is it experience? Is it knowledge? Is it something else? I think it's fundamental for Jenkins and also some knowledge about Jenkins. Yes, some knowledge and maybe the whole knowledge of what Jenkins is, how it works and so on. Because frankly, there are lots of dark places in Jenkins haven't been into. There are lots of things I discover on a daily basis on Jenkins. It's a huge project. It's an old project. So you can't know everything. Even Mark does not know everything. I don't think one person, even Basil Crow, doesn't know everything in Jenkins. So you should know more about Jenkins, of course. But I'm not even sure one mentor should know lots of things about Jenkins. He should know what it is, how it works, some things about the network, maybe Java, of course, or Docker. But I'm not sure you have to be an expert in Jenkins to become a mentor, frankly. I think the main motivation would be the desire to share, to grow, to learn. That should be enough. If you're curious and ready to spend some time, I think that should be enough, more or less. We'll see. We still have not one year, but we still have a few months for you to decide if you'd like to become another GISA contributor or a mentor. We'll see. I think, yeah. And frankly, if you continue working on open source, even if it's not Jenkins, you will learn lots of things. Hopefully you'll find welcoming community. All of the open source communities are not that welcoming. So sometimes they don't want to spend time to explain to newcomers how things work and so on. So it's sometimes difficult to get some knowledge to grow within some communities. But of course, Jenkins is kind of welcoming community. I think it's quite healthy and benevolent. So if you'd like to stay with us until next GISA, please do so. Try to do some PRs here and there or to finish or contribute to this project even more. Hector, our first will be coming soon. I'll be part of that. Yes. And if you'd like, if you have some ideas that you think you won't have time to implement before the end of GISA, don't hesitate to create new issues, work items, and then maybe in September, label them with good first issue, October 1st and so on, so that anybody could come and try to help. I know it's not yet part of the Jenkins CI, so I don't know how this would be welcome. But I'd like that we integrate your repo into the Jenkins CI organization before October 1st, so that people would contribute to Jenkins CI through your integrated repo. That would be really cool. And you could be starting to contribute as some kind of mentor because it's your project, you know. And I think this would be a nice experience. Because maybe you will hate it being a mentor. That would be nice if you know it before GISA. We'll see. Yes. Thank you very much. Cool. Pito doesn't mean anything. Whatever. Is there anything you'd like to talk about before we wrap it up? We haven't discussed, I don't think we have discussed the goals for this week, other than the OpenPRs. Are there any other goals? I think there was one. Really? I thought I had to put all the ones for week 31, 32 and 33. Let me go ahead and check if you have something to share. I haven't seen. Go ahead. Yeah, this one. Use dependent board and update CLL to keep. Okay, this one is integrated. It was listed, in fact. Yes, but we haven't discussed it. You're right. This one could take quite a lot of time, unfortunately. Depend about, I don't know. We've already discussed that. We have clicked on the links with thoughts were valid and nothing happened. So I don't know if we should open an issue at GitHub or get some help in a way on another. I don't get it. It works on my fork. Why would it work on you? I think we are doing something obvious that we are missing something obvious. Yes, so I don't know how to open support. I'm going to have a discord. Gitter or something. Okay, so yeah, this one, first of all, trying to get dependable to work. I don't know how much time it will take. I don't know if we have something to do or if a bug in GitHub will see. As for update CLI, that's a whole other subject and it's kind of a difficult tool. It's not an old tool and the documentation is not that good. Sorry, Olivier. Olivier Verna is the main contributor, is the creator of update CLI. It's a fantastic tool, but the documentation is not as good as the tool itself. I know it's also my fault as everybody else because if the documentation is not that good, once you have understood what is going on, you should make a PR and make better documentation and I had a few problems with update CLI and I haven't done any PR yet regarding that. I've only created some issues, no PRs. Yes, it's not an easy one. Olivier used to work for the Jenkins project. He was part of the infra team a few years ago. He's a very nice guy, but that's not the problem. You could give a try at update CLI. I may have done a PR that I have closed, I think, regarding update CLI, though we may find something that you could begin to work with. Let me check. So in the issues... No, it was a pull request, my bad. Okay, EPR, update CLI. It's better when it's correctly written. Okay, it was just a reference to update CLI, my bad. Let's go back to the repo and have a look at my fork. Do we have a branch that works on that? More or less? Or not? We'd find that. Okay, I don't have it. I did win it. That's a bad thing. So Dependabot is a must-have. Update CLI is a nice-to-have thing. You would have to invest quite a lot of time before having just a tiny bit of update working. That's the way update CLI works. You have to spend quite a lot of time, the first time, in order to gain some knowledge. And then, when you feel more confident, the subsequent updates go way more smoothly. So it's not mandatory. It's not urgent. It's a nice-to-have if you have time, too. Okay, and if you're looking for examples, I've made quite a few ones for the Jenkins IO website. It's been merged a few weeks from now. So you will find the PR, or you will find it's a directory called a DTI, in which you will find all the definitions. The thing is YAML, which is not that handy, but anyway, it's YAML. And you define in the YAML, sorry, you define one YAML per tool you want to update. For example, if you're looking for Node, you will create a Node.YAML, in which you will say, okay, I will try to find in GitHub, for example, the last version of Node. Then I will try to find the latest version of Alpine, for example, if you want to use a Node Alpine Docker image. And then when you have created that version of latest Node and latest Alpine Docker image available, then you will try to find the files where it is referenced, and then you will make the update. Lots of regular expressions and YAML. Yeah, it's definitely a challenge. But you got that, of course. So do it if you want to, if you have time to, if you're interested in learning a new tool to update. Dependable already makes quite a few updates that work for us. It's able to update the Dockerfiles, which is our main source of code. That should be more or less enough. Update CLI is a bonus. Fine with it. And the last one was find a way to auto make the fork and clone part of the tutorials. I think you copied right away the config.xml in the test you do for the various Jenkins tutorials, Node, Python, and so on. It's hard coded in the Action file. Okay, Wari? Yes, it's hard coded with some variables for the links. Yep. But maybe, I say maybe, so this one is not monetary either. We should try to clone or get the file directly from a GitHub repo. The thing is the official tutorial repo is not finished, of course, because the end user has to do the work all by himself. So we don't have a working Jenkins file in the official sample repose. I don't know if we should use yours, for example, which had the definitive one. I don't know. It's more of a discussion, you know, you don't have to do this part. And the title is not that good anymore because that was written at the time where we were thinking that maybe we should fork and clone locally because the end user shouldn't do that. And that's not the case anymore. We decided a few weeks ago that no, the end users should be able to fork from GitHub and then clone locally. We don't have to do that for them. It's just that maybe we should reuse some of the scripts that were written at that time to fork and clone locally or not, just for the testing part. Once again, not mandatory. And that's all that I had. Did you see anything else that you wanted to do this week? No, I don't think so. That's it. Okay. Anything regarding school agenda or is there a day when you won't be available this week or? This week shouldn't be, it should be normal. I may get exams in September, late September or, but they don't last much. It's like three days. They take all the exams and it's in the morning usually. So Jenkins meeting office office hours meeting within evening for me. So it won't be a issue. Okay. You said end of September. End of the September. Yes. So, yeah, Jesus will be over. So that shouldn't be a problem. It's more for the presentation. We haven't decided yet. Yes. That's the subject we should discuss next week. Yes, of course. Yes. Thank you for reminding me of that. I had forgotten. Okay. Anything else? No, that's it. Okay. Thanks a lot for your work and your time. So I think we'll wrap it up. I'll try to pause the video from 24 to 48 hours on YouTube and modify the existing community Jenkins.io. I think that's the best thread regarding this project. So best of luck for the issues you will have to solve this week. And we did to get in touch via. Gitter element or our shared document. Once again, thanks a lot and have a good week. Bye bye. Thank you. Thank you.