 Hello, everyone. This is a GSOC Jenkins Docker base quick start weekly meeting. We are on the 31st, I guess we should say of July, 2023. Today we have Jean-Marc, Ashutosh and Bea Viento. So last week was a pretty busy week. I would say there were a few left over from the week before, you know, in the PRs and work items, but most of them got solved this week. And last week program was difficult. Also, lots of things I had scheduled, planned or hoped that they would get done. And this week there are also quite a few things that have to be done. But first of all, I want to congratulate everyone in the team because last week was an important milestone. We finally got rid of the bash files. So now our work should be working for Windows, Linux, Mac and maybe some other OS. As long as you've got Docker and Docker compose. Well, that should work. And it has been demonstrated on last week's docs office hours Asia. And after a little tweak from Mac wait, it worked beautifully. So congrats for all the work. The work of all the previous weeks led us to this milestone. And I'm really happy this is showing now that we are on the right track and doing good things. And I'm proud of us all. Now, let's see. I hope you can see my screen. Let's see rapidly what we can check for last week work. So the reverse proxy issue we'll see later on, but it's done more or less. The GitHub action and experiment you've done more than that. I should touch because we have something that works that starts Jenkins that waits until it gets stabilized, you know, started for real, then listen to the job building and waiting until it's done and then shutting everything down. It works. It's beautiful. Now we haven't started yet the discussion on community Jenkins IO, but no hurry about that. The Node.js and React apps with NPM works. There is still some work to do around the documentation. But that's okay. The push the images to the hub is not finalized yet because I'd like some tweaks. We'll talk about that in a few minutes. The get rid of the mandatory bash files. Yes, this one is done. It's over. You. I'm happy about that. Hello, Jean-Marc. Yeah, I just wanted to say congratulations. I didn't want to interrupt the flow, but I was making gesture. Oh, couldn't see you as you were making no noise. No, no, and as you touch heads, a lot of autonomous contributions in that. So just want to emphasize that. Yes, we are progressing on that area too. And that's really important. We wanted you as you touch to progress in autonomy. And frankly, last week and the week before I'm happy with the outcome. Really. Thank you and congrats to that. Now, we have some work about pipelines, about how to automate the full clone part of the tutorial. We see that, but it's just for the testing part. This week, we should be working also on the update of the plugin list. That's important so that end users don't see lots of things to do before even trying their tutorials. You know, so a clean working out to date Jenkins instance. Then if time permits, we should use the built images from this week and get rid of the Docker compose build. At least for the end user, not for the test, which is that later on. We have some tweaks to do about the GitHub action because for the time being, I don't think we are testing the real tutorial job. We are just, yes, using the simple job that's created. That's cool. But that may be not enough. We'll see that later on. I should have wanted to say something. Go ahead. No, I was just agreeing with you. Anyway, we'll talk a little bit about jcask and the proxy warning configuration later on. We made a lot of tests. I made a few experiments and Damian tried to help me. We'll see that. And in the end, we'll see if we can use gitbot tools to configure jcask. We already talked about the box office hours once more. Congrats. Well done. I was smiling just by myself alone in my office when I was looking at the replay of the video on YouTube. That was cool. That was a good thing to see. Last week, sorry I may, no, not I may. I did not wait for your approval for a few pull requests of mine because I was kind of a hurry and it was not changing the end product. I added some quality insurance products, I would say, in the repo. Adolint for Docker, Kodasi for the shell files. There's also something for the markdown files. So don't be afraid. There are 975, I think, security alerts on the repo, but more than 700 of them are related to the markdown because on a lot of lines, we're not respecting the AT characters pull line rule. So no worry. That's okay. It was just to give some more quality to the code and just in case anyone wanted to contribute to the repo or after GSOC, there are lots of things that could be good first issues, you know, some things that are quite simple to fix. But yes, I didn't wait for your approval before merging into the repo. Those tools. Bad mentor. Next, by the node tutorial. So it's working, but the official documentation say that we should click on localhost on the port 3000 of course because we're supposed to run that on our machine. But that does not work for Gitpod. Of course, localhost on the port 3000 doesn't work at all. So we'll have to put warning in the documentation. I think you almost done with that, Ashutosh. Yes, I've updated the Jenkins file to include the link for the report separately. And maybe we would have to change also the sample repo in a way or another so that it works with Gitpod. We'll see that updating the documentation is really important for that. Now, lots of pull requests were closed because they were finished last week. Congrats for all the work. I'm really happy with that. So the documentation has been updated because we are not using the bash files anymore. We also have updated the GitHub actions in order to not use the Jenkins in each shell file you were using before, but just the Docker compose up and down. Now, the set set file and offline convention, that's something that bark weight brought to the repo after your demo because he experienced the same issue I had on Windows, which is a bash file with control M, I think, at the end of the line. So bash couldn't found and so the Docker image couldn't be built. So he just added that to the repo. And of course, whenever you have already cloned the repo, it's too late. You have to cloned it in another place and we start from scratch. But for the end users, I will experiment on that later on. They won't have any problem with that. So it does work. Thanks to that on Mac linux and Windows. I see Mac, but John Mark, did you try the last main branch on a Mac recently? I need to confess that because of the pile up of work. When I returned from holiday, I'm still catching up. And I apologize. I'm late in reviewing Ashletosh work. I was not trying to put blame on you, not pointing fingers or whatever. It was just a honest and naive question. Don't worry about that. So it's supposed to work under macOS. I think you're using linux or are you using a macOS? I don't have macOS, but I use popOS right now. PopOS. Okay, so it's a linux flavor of which kind of distro? I think derived from Ubuntu. Oh, okay. It's okay. I thought it was Dubuntu. Okay, it's Ubuntu. Got it. I think we can use GitHub action with macOS. I think so, yes. Isn't their price with that? I don't know. Yeah, I think there is option macOS in GitHub action. I was also experimenting with using GitHub actions on Windows too, but they didn't have Docker compose installed on default. Oh, so you mean that you can have a Windows machine or a macOS machine in the cloud from GitHub for free to do your tests? I'm not sure if it's free because I didn't try it. I was thinking but Docker compose is not available on Windows 34. Because I thought that you only could use macOS or Windows with a local runner on your own machine, so I was wrong, I guess. Good to know. No, I could be, I could be wrong. I haven't tested it. I was just thinking but it doesn't have Docker compose and it's hard to install Docker compose because it uses Docker desktop then we have to sign in Windows. Oh, okay. Thank you. Next, I already told you about the security updates I made last week. No, I told you about the tools that could help us to get some security layouts, but I also made some security updates by security updates. I mean that last week we had Jenkins LTS security advisory, so we were at version 2.401.2 and last week the 2.401.3 got released because of security vulnerabilities. So I made a pull request to update that and some of the plugins that we had also had some security issues, so I updated them at the same time. After that, we also had installed GH in Gitpod because for our tests, sometimes we need to have GH in the console and I was fed up with installing on each and every workspace. So it's now part of Gitpod and of course to install GH in Gitpod, I chose to have a custom Docker file for Gitpod. So we now have a specific image for Gitpod with GH inside. Actually, you also added GitHub Action for Python and Node.js tutorial because up to now we only had the Maven and Python. Maven, and that's all. Or Maven and just the first example. Am I right? I didn't get it. You paused for a second. Can you repeat it? Sorry. A few weeks earlier, you were testing with GitHub Action for just the simplest example you had and then for Maven. You know, with GitHub Action starting the Jenkins instance, starting the agent and then testing a simple job. Yes. And now you added that for the images that you created for Python and Node.js. And of course we'll have to find a way to test not only the simple job but also the job which is linked to the tutorial somehow. Yes. I think I closed the remove proxy rolling because we can't do anything in fact regarding Gitpod not doing the right thing with... Mark, you made a lot of experiments. I made quite a lot too. Damian made some others. And the conclusion is there is something like a magic box inside Gitpod. It's doing something with headers and something that Jenkins can't understand. So we are blocked. We can't do anything for the time being regarding that. So our proposal is just to remove the monitoring for the reverse proxy problem for Gitpod and only for Gitpod because it's important to keep it for longer costs. Yes. That was also my conclusion. And I wouldn't exclude Gitpod because it's a good solution for people that don't have the resources. So let's just navigate around it. Yep. Fine with me. I don't know yet how we will find when we are using Gitpod I guess with some workspace variables or something like that. We have to find the right moment to detect that we are using Gitpod and adding the monitor before launching Jenkins. I think this can be done. You'll find out. So as for the open PRs just before this meeting I don't know if you have opened any other at the beginning of the meeting as you touch. I saw the not tutorial URL on Gitpod. So that's because it's displaying locales on the wall 3,000. Yeah. So it's just about documentation because we can't do anything on the official tutorial repo for the time being. We also have the multi branch pipeline because pipelines, simple pipelines are somehow a thing of the past there. It's legacy, but it's not the way we would like people to start with Jenkins anymore. So, yeah, I saw that you have. Yeah, go ahead. Can you say that statement again? It was a little bold. Scripted pipelines compared to declarative. Is that what you meant? No, simple pipeline with just run branch and I would like to get rid of that. And Damian and Mark also told me that it's cool to have pipelines, but it's not the way we're supposed to work these days. Lots of projects use lots of branches PR and so on. And the beauty of the multi branch pipeline is that automatically as soon as you add a branch, as soon as you've got a PR. Okay. Building on your website. Right. Okay. Got you. Yeah, I am. I'm fully with that. Yeah. Oh, cool. Because I think that was pretty much a bold. No, no, no. Okay. I'm relieved. Thank you so much. No, no, but I thought I heard something else. So there I was a little bit. Oops. But here that statement. And we need to like pushing for upgrades. We need to review our way of teaching people the best way to use the product. And so let's be bold. Too many people doing scripted pipelines out there. Yeah. And since that sometimes, not sometimes often in the community Jenkins, I suppose people say, I've done that and that and that. And my engineers have been scripting like crazy. And now I'm stuck. What should I do? Well, in the first place, you should maybe not have used scripted pipelines. Anyhow, work items. Last week, we had 17. We are down to 14 today. And so there are still a few ones from last week, but they are almost done. So there is a githpod rivers proxy setup is broken, but it's okay. We know it. We accept it's failing. Fine with us. We'll find maybe a walk around one of these days or not at all. And that's okay. Then we have the push the images to docker hub. This one is already working more or less, but there's something that got me puzzled, you know, the tag of your image was that big. And it's fine. By the way, I hadn't understood that it was because it was perfect by the name of your branch. But I asked for change, which was get rid of the prefix, at least when you were on the main branch. Yes. So do you see how to get this done. Yeah, I have come push the comment, but but you until suggested something else, which I'll be working on after this. Okay, I have a look at that. Thank you be having to. Well, let's do we have forget about pipeline with all you told about that current not just tutorials can deal with get but it was about the port 3000 that's okay too. We have Docker hub images. So this one will come after the first one, which is, I guess, let's use in the darker compose no more build but just the definition of the images. No, okay, it's pixies push the image to the Docker hub. Okay, my bad. Yeah, better than that. This one is of low priority, you know, find a way to automate the fork clone part of the tutorials. As I said in the introduction, it's based is for the testing part, you know, for the time being, we're just launching and simple job. And that's all we'd like to launch a job for a real tutorial. But to do that, we have to clone locally and or fork the existing sample tutorial. So we have to find a way to do it automatically. Just cloning the official one is not that good of an idea, because there is nothing in the Jenkins file. So I guess we should clone something that already has all the steps for the tutorial. So the git checkout, the build, the deliver and so on, you know, so we'll find out something I think it's not a very well defined work item will have to discuss experiment, comment, and so on. It's not something that's really straightforward. And I repeat, it's not high priority. Yes. The next one is keeps a plugin list up to date when building the Docker image. This one also will have to discuss, I guess, because I wrote when building the Docker image because it made sense to me that before, or why we are building the Docker image should maybe keep the plugins up to date. But there may be other ways to do it. You'll find some by yourself. One I had in mind was that maybe you should do that at another time, like for example, we could have a GitHub action. That does on a weekly or daily basis spins up Jenkins instance and then tries to update the plugins and then if ever it find that there are plugins to be updated then creates by itself a PR to update the main branch. So maybe we don't have to do it while building the Docker image. It's not mandatory. And once again, maybe we should discuss that it's just out of my mind. Maybe it doesn't even make sense for you. Let's discuss that. Yes. And the one which is linked to Docker push and build is do not build the images for the end user use pre built images. I think it's been free week or so that I'm saying the same thing. As much as I'd liked that anybody on any platform should be able to build the tutorials. The thing is, some people may face some issues because they are using a platform that we haven't tested. So we decided to shorten the list of the supported platform and just make it work for IMD 64. So any PC and R64 so arm 64 bits for the time being. Of course, I have some other ideas, but we'll see that later during the summer or maybe later. We'll see. Anyhow, so for the time being, let's just make it work for PCs and arm 64 max or arm 64, whatever. Next one, get the GitHub action to test the real job. So that's what I was asking earlier. So we are testing for the time being the simple job and we have to find a way to test the job which is linked to the tutorial. But once again, we have to discuss its link to other work items. So nothing is really clearly defined. So it takes more time than this week. That's okay. And for the two last one, I'm not so sure we'll do these ones because we now know that Github doesn't really work. So we'll see. The last one is use Github tools, configure jcask. I think I should click on that so we should know better about that. But I think I was thinking of removing the monitor about the reverse proxy when using Github. And we could do that maybe with the Github tools. But I think I'll do this one because I'm not so sure it's useful that you spend some time on this one as we already know it doesn't really work. It's not that important. Go ahead, John. Well, I don't want to interfere into the project management and I know you want to have fun too. You know what? Unless we flip a coin to know is it Ashutosh or Bruno or you Bruno that does this. Oh, yes, Ashutosh. It's not my game and only my game. If you want to address this one, please do so. I was just, I don't want you to spend too much time on that. But if you feel like you know something about that and want to, even if you don't know anything, you want to try it. Go ahead. No problem with me. Anyone is free to. I don't have the global view, but the most important thing is what do we want to deliver what contributes to the objectives of the project is is you will remember this. So focus, but on the other side, although we're working together, we don't, we may not take all the work from Ashutosh. He needs also to learn the balance. Go ahead. This issue might be similar to the previous one I've done so I think I can handle some. Just my two cents there. I don't want to start a fight, but especially these are interesting problems. But you're right. Sometimes I tend to say this is mine. It's mine. It's mine. Only mine. Don't touch, but not this time. It's not like maybe you can go on. I don't know. So just for everybody, we need to have a clear view where we heading, what needs to be done for that date and that's how we do decisions like in a stand up. But here in this particular case I'm interested that Ashutosh learns as much as possible and we just enjoy watching him doing it. So Ashutosh, did you have to create a Docker hub account or did you add your already one before the GSOC project? No, I did the already one. I didn't do it anymore. That's cool. But did you learn anything with Github Action, coordinating Github Action and Docker Hub? Had you done that before? No, I hadn't done that before. That was new to me. Okay, but you did it beautifully. It works. That's cool. I had another issue. Oh, really? That when we use Docker component, sometimes say that the resources are still in use. Yep, I had the same problem. You're right. But I didn't take the time to open an issue. So how does it free that one item are still in use? After the down, you're right. Yes, yes. When we try to turn them down there, one is I think network is one network and one container. So that it's still in use. Yeah, I've seen that. Not every time that I've seen that. Does it mean that one is crashed? No, I think it's the volume we have created for the sidekick container that one keeps learning because it's used in multiple containers. Okay, so maybe check that we close it correctly when it's done. I don't know. Go ahead. I haven't looked into it in detail, but it doesn't work with just Docker Compole down slash less volumes. Those two things are still running. We need to work on that. Otherwise we need to take the baseball bat out so that it shuts down. This is a little bit too bloody. That's an idea. I like it. I had a baseball bat in the office when I had and above it was ultimate debugging tool. But after a while I removed it and brought it back home because I said one day somebody is going to use it just by rage. That's too dangerous. For me it was just a joke, but somebody would slam a monitor or something. Anyway, sorry to come with my stories. As long as it's not a colleague. Okay. What I'd like at the end of the week is that we have the Docker images pushed and used inside the repo that would be really cool. And what else? I think that's the main thing I would like to see Jean-Marc Bavinto anything you would like to touch to focus on this week? No, but I like the question because it's about focus. So it's a great, it's a good question. I have no objection to this week's focus. Bavinto. So what was the question Bruno? Can you restate it? I think the question was, are you okay with the points I just made about which subjects should Ashutosh focus on this week? I said build and push Docker images and use them in the workflow to get rid of the Docker build phase. Completely. Yeah, that's what I was insisting on. So I was asking, are you okay with that? Do you agree with me? Or is there anything you would like to see finished this week? Okay, I think I'm okay with it too. So you agree with the proposition, right? Yeah. Okay. Cool. Ashutosh, is it okay with you or are you afraid of this week's milestone? Okay. You're okay. And you know what? You teach me something last week about Docker Compose. I think I had never seen the use of Docker Compose profiles. Yeah. I just discovered them and I was happy that it will work beautifully. Ashutosh, you made my day with that. Yes. That was great. Thank you. Yeah, because I had made the draft PR proposal and to solve the problem of getting rid of the shell files. And frankly, it was way more complicated, not as pretty profiles made it more beautiful or simpler. So that's, yeah, that's great. I'm happy with that. Okay. If there are anything you would like to add Ashutosh, would you have any impediments or questions or if everything okay? I think it's okay. Cool. Anything special at school this week that would change the schedule or are you as available as last week? I think this week might be a little busy, but it's not that much. I would say it's normal. Okay. Previous week was a little too free, but this week will be normal. Yes. And don't forget John Mark's advice. Show your face to your teacher. Yes. I'll show them. Okay. Bavio and John Mark, anything before we wrap up the meeting? To catch up with the project, project is moving well forward and I'm running behind to look at the PRs, what has been done and take ownership of the issues and say so that I'm useful in helping the project. So sorry about that. I'm trying to make that this week, although I have a busy week. Yeah, of course. And sorry, I was also maybe too much pushy last week. So it's also my fault. Yeah, but we want to have results. This is normal and natural. Okay. Thank you for your understanding. Baviento. All good for you. Okay. Thank you, folks. That's a wrap up. The video should be available from 24 to 48 hours. And see you later in the week. Don't you forget we have Gitter Element. Choose your tool of your weapon. We can discuss on that. There is also mail. And if ever you need some time to pair with someone, don't hesitate to ask. You never know. That could work. Okay. Fine. See you folks and have a good week. Okay, bye-bye. That's all folks. Thank you. Well done. Bye.