Hello everyone! This is Giso Jenkins Docker base quick start meeting and today we have BeaVionto, Ashutosh of course, Jean-Marc Messin back from vacation. Thanks a lot for coming. And Stefan Mail who is also coming back from vacation. Thanks a lot for being here. So for the people who weren't aware, I think it's just Stefan, Ashutosh has moved back to school. So he's not at home anymore. And of course he doesn't have as much time as he used to have before school. So don't get upset if you think that things aren't progressing as fast as they were before. It's perfectly normal. So, what do we have? A few action items will detail them maybe later on. But maybe first of all, let's, I don't know how this is called, you know, temporarily checking. How is everyone doing?  Ashutosh? Yes, on my side it's fine now. This week I got busy on some chores for here, setting up my desk and all that, going to bar groups and all that. So now I'm set up. Okay Jean-Marc, how was back to home? Everything went well. Had some surprises in the garden, but other than that, ready to fly in and get in sync with what has been done while I was away or partially. So looking forward for the update. Cool, and nobody is mowing the lawn just next to you today. You have two screens or more, so it's really more comfortable where you are now. Just very shortly. Do you want to see how flowers of Radis look like? Oh, Radish flowers. Yeah, I think I know them. But yeah, of course. They grew over. Of course, it's kind of hot and dry. So of course it went into flowers. Yes, but keep the seeds and you'll get some new Radishes later on. Why not? Okay, thank you Jean-Marc. But we will miss your background. I don't mean that I don't like this one, but I was preferring the one with a lot of trees behind you. It was way more relaxing for us at least. Stefan. Yes, you want some private chatting and everything. So what's back? When I went back from holidays, my neighbor had been a huge wall between us. Oh no. It's great because it's nice. They did it nice on my side too. So in fact, I'm super happy because I didn't pay any on that and that looks really nice. So I would probably buy them something to thank them. But that's what I discovered. But I was having a alert from my camera outside saying, Oh, there's people in the garden freaking out and in fact, they were building the wall. So that's fine. Yeah, nice. Baviento, any surprise on your side? I don't have anything because I guess it's usually my own work. Of course. Only French people are talking about private stuff. Yeah, of course. The other one are just walking, you know, that's the way. Yes, indeed. So back to work now. Thanks a lot for sharing that with me. Poor request. I know I gave tons of work to Ashutosh because I was kind of afraid he would be out of work with me on vacation two weeks ago. So the work from two weeks ago kind of shifted to last week and it's not perfectly finished now but that was something to expect, of course. The Python tutorial is ready to review. Am I right, Ashutosh? Yes. I forgot it was about draft pull request and so I did. Yeah, I should have told you I had a doubt in fact because it was already working for me. So I was wondering if you still had some, you know, some screws to tighten or things like that. So I let it this way, but I maybe I should have let you know that I was ready to review. So please mentors have a look at the Python tutorial and review so that we can merge it as soon as possible. Next, there was a big one about GitHub actions PR. I had given a draft PR as an example, but frankly, it was working. It was working, but it was far from complete. So it was kind of misleading. I was thinking that it would be kind of easy to apply that draft PR to the current code. And no, that's not the case. There were a lot of traps, tricks and so on. So that has proved being difficult for Ashutosh. And some of the difficulties were all my fault because I had made some had done some how to do that shortcuts and things that were working automatically. And I think that was because my code was perfect. No, it was just because jobs were running all by themselves because Joe Mark you asked for, you know, every two minutes, some jobs have to run all by themselves. And I thought that my call requests were doing all the hard work, which was not the case. So my phone. Ashutosh, is this one ready to review too? Yes, yes, I have added the post command that turns on the build. So it's working now. Okay, fine. I'll review that later on today. And for the people asking, why are they doing some GitHub actions? I mean, people in the audience, of course, all of you know about that. That's because that the very first step, it's kind of easy to set it up. And it's, you know, kinds of baby steps. So we know how to test our Jenkins instance. And then later on, if time permits, we'll convert that into Jenkins job Jenkins pipeline that we'll check on the northern Jenkins in CI. Jenkins.io or something like that, Stefan, you know, things that your team handles for Jenkins project. That's why. Good news. If this one is finished and the Python tutorial is finished too. And we had two other work items. I was searching for the right term for last week, which were a problem with the SSH key generation, but it got solved. Maybe merge. I can't remember Ashutosh. Did it got merged? I don't want to issue it open, but there is no PR. Because it already works. Yes. Okay. Thank you. Then we have and still have a Gitpod Weverse proxy setup, which seems to be broken. Has any one of you any input hints, feedback about this one, because I'm kind of puzzled. I thought it was just the matter of having the same thing in the jcask configuration as the one we have in the browser address bar. You know, because for the examples I have, most of the time I just have to change in the UI so that the URL in the Jenkins setup is the same one as the one in my browser address. And then I'm done. But it doesn't seem to work for Ashutosh. So if any one of you knows anything about that, please let us know. I'm writing that down. I don't remember. Here, just by priority, I thought having a look to the two PRs and then look or what would help Ashutosh most. I think he has spent. Oh, go ahead. Sorry. There was proxy, proxy issue. I spent today and the day before to on it. And it's not I've tried nginx and it's a party to and another one, but it's not working. I think it's because good for users for in the URL itself. It mentions a port in the UI. So it's when it's using the port, it mentioned that in the URL. I'm not sure about it, but I think that could be the case. I just covered something this week also speaking about that because I was making some tests on a kind of library I'm trying to write using curl to interact with Jenkins, whatever. As long as you don't click on the make public. It looks like the URL you are trying to use is not accessible even from within the github workspace. You know, I was trying to make some curl to my 80 something github IO, and it wasn't working. And then I clicked on the very bottom right of the screen on make public and then bound automatically it started to work. So I don't know if this has anything to do with that, but maybe it's worth checking it out nonetheless. Berbjanto, do you have ideas or experience on that? I haven't. I haven't checked it. You don't have to be sorry. You were just in case. Sorry, go ahead. Yeah. Okay. And Stefan. I've never played with with github most of the time, so it's brand new for me. Okay, I'll put my teeth in that problem and try to think in and share so I need to get my week organized correctly. Yeah, but then I will have I have a look in and maybe discuss with Ashutosh to know what he already experimented. To clarify, you said that even within the gate pod, the resolution is not working so so the reverse proxy is not working even within it. As far as I understood, yes. So Bruno, go ahead. And you can know it's typing so it's not. Yeah, I'm only two neurons. So I can't understand why I'm typing both busy. When you say that the reverse proxy is not working, you mean even within the gate pod, not from outside. Oh, yes, of course, within the gate pod workspace, you know, if ever you are trying to get it to work within the Jenkins UI or from the workspace with a call command, it does not work. But I haven't tried yet to solve the problem by clicking make public on Ashutosh example. I did it on a separate. Because from from the back from the, the SRE point of view, the fact that to to when you push the make public that probably open ports and do the routing and everything. So it should not have any effect on the on the inside of the gate pod. Yeah, from the top of my head, of course, maybe they have crazy stuff that are making it work but but I don't see the point of having any any rules within the pod. But maybe the environment is running on in a pod in a communities pod has some special behavior. Just a reminder, what we're trying to do is to get rid of the warning in the UI in the UI. Because if somebody we want to show a tidy Jenkins system and with no warnings. Yeah, I got that. Yeah, you're right. Of course, I got that. Yeah, no plugin to do and yeah, no reverse proxy because any error with why should I try this tutorial. It doesn't start clean enough for me to invest time in that. That's why and what puzzles me is that it used to work. Or did I daydry. Yeah, yeah. I also tried to remove the, like there is a dismiss button in the UI. So I tried to search for if I can do that with terminal inside the gate pod itself for running the Jenkins, but I couldn't find anything that was there. It's very easy way to do that to remove the warning. Sorry. Yeah, this is the other option indeed so we could suppress the air here I'll do I'll do some research on on it gather trying to understand where is what is causing this error what is the root cause of it, and maybe explore a couple of solutions. Yeah, because unfortunately, I let you all alone, I should touch with that and you spend some time with h a proxy, and another one. I know the term reverse proxy is kind of. Yeah, maybe not the best one in this situation so that may have misled you into a dead end, but none of your fault. I wasn't there and the message is pretty. Firstly, I would say. Okay, anything else about that. Okay, so thank you so much for proposing to have a look at that. I will also have a look on my side, experimenting with github and hopefully the two of us will find a solution in the end. That would be nice. For the python have I've already used it. I've not reviewed it, but it's working for me so I guess it will work also for also. And for the github action, I haven't seen it work yet but have to see what has been going on and hopefully it will work correctly so you're able now to launch jobs. Yes, it was working for me. Well done. Yeah, and I can't remember do we go the whole process like creating an admin token with a crumb and then using that admin token to make the other call request or are we just using admin admin. I'm using token. Wow. Yes, that's cool. Oh, I need to look at that. Okay, well done. Okay. Yeah. Firstly, I used build with parameters in the post command but that was not working correctly. So I just leave the build option. Okay, but that's quite a lot of code lines and that may be difficult to maintain in the long term. I don't know I'm currently experimenting on another repo I'm trying to write some kind of bash library in order to have fewer lines of codes, because I don't want to make a modification in that six months from now. It will prove difficult. We could separate the script. We have to recommend it. And in the data. Yeah, sure. Bevin, so would you have anything to add regarding that because you're the one who proposed to CPR separate the script from the rest. It's just for reliability because quite hard to read. You're right. What else do we have. So, yes, I was not finished when the meeting started my fault. I was trying to get the work items we supposed to work on this week. So the first one was build a Node.js and react app with NPM. Once again, there is a draft PR that show that how this could work is not perfect for me it was working but of course it needs a lot of TLC that just sample get to start in some kind of bootstrap. We have another one which is come on. Push the images to docker hub. This one will say I would love to see that and why would we push the images to docker hub by the way. I was discussing with Damian DuPorte a few weeks ago and he told me that I think we already had the discussion but that just summary. I remember somebody on the non-supported or untested platform was trying our tutorial and it was not working because we never tried on S319X for example or PC64LE then it would be kind of deceived. Of course frustrated. That's the term I was looking for. So the goal for that is to provide a set of images for a definite list of architectures platform so that we supply it for example for AMD64 and ARM64 and that's all. That's it. So we'll say in the documentation this tutorial has to work on an Intel AMD whatever or an R64 machine if ever you have something else you're on your own. So the goal there is to build regularly and to push to docker hub the images we're using so that we can once more simplify the tutorial. But the build process will have to keep it somehow for the test part so that the CI one day in CI Jenkins I can build images locally test them maybe on some other architectures so we'll know one day if we can put it to another architecture. That's just the goal of it but there are quite a few challenges in fact in that once more it's GitHub actions so I know you learned about GitHub actions quite a lot recently Ashutosh. So that's that should be an easier step than the first one you had with testing with GitHub actions. But also you have to learn a little bit about Docker registries. What are they? How can we connect to them? You'll have to add some variables. How are they called I think they are called secrets in your GitHub repo. And so on. So that could go fast or very slow. We'll see. Would you have any questions about that. In this script I used Docker and pushed my custom image before so we'll be similar with variables something like that. And I think we have a next one. Oh, this one frankly the milestone is next Sunday. I'm not so sure we'll make it. Once again, it's Damian's fault. We were trying we were discussing about the shell file. It's also because of Mark and because of your mark. We all say okay but what about the Windows users. How will they do if they don't want to have WSL. Of course we propose to write some Docker shell. Power shell sorry files but that's not good enough. So the goal of this one is to get rid definitely of the bash files and just work with the Docker compose up and that's all. So once again, there is a draft PR that I wrote a proof of concept that kind of works. It still uses your Jenkins in its script. Of course we won't put it into the trash but this script now will be part of a Docker image and not directly used on the end user machine. So I tested it on Windows and it worked. I did it on Linux AMD 64 and R64 and it also worked so I'm pretty confident this one will work. But it may make some knots into your head. It's difficult because we are all accustomed to using these bash files and now you have to think of another level with another Docker file that will use that bash file. So you will maybe need some time to think about it. To draw some schemas some graph something on a piece of paper in order to understand what it does and why it does it this way. And why we are shooting that and the whole workflow and so on. So you may have lots of questions along the way and that's perfectly normal. Oh, Jean-Marc, I know I talk too much. Is there anything you would like to add? No, the thing that we need to be aware of and think of and this is what I was thinking about. And maybe something we could discuss more in depth offline is we need to make sure that the objective milestones and priorities are correctly set. And that we work on achievable goal. Currently I don't have the global view. So I don't know where we want to go and basically this arbitrate is this interesting, useful or critical? Yeah, the thing is we're not using Kanban yet so we have milestone but within the milestone if ever the milestone was correct because I did it out of the blue. We can't reorder at least in the GitHub repo directly. We can't reorder the task for a defined milestone. So yes, we should maybe talk about that. I don't know if we have the time to create a Kanban. I think that Hervé used the to-do project stuff from GitHub to be able to order issues. You may have a kind of a solution by that way. We wanted to go that way but it's just at a certain point beginning of July, we thought the milestones were precise enough. Numbering the issues may be good enough. But don't forget that currently Ashutosh is the only one working on these items and we're just looking. So the danger is to over engineer it and to add yet another tool. That's why if what you say is bringing that kind of solution by just putting a number in the beginning of each line of issues and that way that should be sorted by that number, don't you think? I'm not sure saying that from the blue like you said. But first I need to get back and have a discussion with Bruno just to check. But this is my worrying self saying, well, what is important, what is not important and do we focus on the right stuff? I think Ashutosh already heard that song. Yeah, the thing is I don't want Ashutosh to be out of work so maybe I gave him way too much work and so that's normal if he can't succeed I would say in the milestones and that's pretty bad for his feelings about the project. That's right. But we could return the question at the end I don't want to interfere and ask Ashutosh for the feedback what does he plan to work on this week and to deliver. But I don't want to interfere in your meeting. It's not my meeting, it's our meeting. I'm coming back from holiday so my mind is still frozen. I think there are a few quick wins for this week that maybe could help us a number the priorities. The third thing to finish I guess would be last week's with the Github Revers proxy. So if we can help today or tomorrow to close this one that would be nice. Then at the Python yeah go ahead. Yeah, are you talking about the task for Ashutosh or for the project as all? The project as all because I think this task needs your help. Yeah, reverse proxy I agree. If ever we were to make another demo you know this week on the docs of his hours for example. That will be troublesome you know I don't want to see that anymore. Yeah, I agree. Third thing then I was talking about quick wins because Maven was the Maven tutorial was difficult to write but once we wrote this one then Python one was kind of easy I would say Ashutosh. Yes. For the Node.js and React app it's more or less copy paste and then change a few things remove a few packages add a few other packages but the workflow should be more or less the same. So this one is a quick win maybe you could do that only I don't know if the others will agree with me but that could be something you do in the beginning of the week that you get the right stamina you know I can do that. Yeah, the project does work for me and then tackle with something more complicated like maybe put the images to the hub and maybe at the end of the week work on gets rid of the mandatory bash files but I'm kind of reluctant for this one because I'm not so sure you will be able to finish it by the end of the week. And frankly finishing the week on something that doesn't work. I'm not so sure it's good for you or us. Jean-Marc what do you think. For me it sounds like a very good plan and well well thought so I'm interested to hear what the shoot us has to say on that. Yes, I also think that the Node.js one should be done. Okay, and what were the two last words that you said in previous sentence. Okay I don't remember Node but I don't remember. Okay, but the plan is let out by Bruno sounds good and these priorities are sound. Cool, thank you Jean-Marc. Fine with you Baviento. Thank you. What is I think that's all we had for this week's work items. Let me check. Yes, I think we're good to go with those. So the milestones were kind of arbitrary. I just cut them into weeks so that we don't have have the tunnel effect you know each week we have to deliver something but the priority I did not discuss them with you. So if you don't agree now it's time to tell me about that so we can just change it. The ones for this week's were because I had some discussions with Damian with Marc and that's the things that shocked them when we were demoing the tutorials. So that's why I put them in a higher priority in the milestones but for the rest of the milestones I don't know if we can talk about that or if the right place, right time. But maybe some of them are more urgent and should be moved. Maybe not. Come on Internet you can do that. Let me check the issues. It's kind of small I guess for you. Let me make it bigger. So milestones so we still have seven of them. Last week was week 29 we always talked about that we have seen the ones from the week 30. So next week we should have a small one about installing GH in Gitbot. Frankly it's not urgent. Then this one may also move find a way to automate the for clone part of the tutorials. Lots of you and others like Marc Damian and so on said that would be a nice part to keep but for the automation part in the CI you know for the tests but for the end user. That doesn't sound like such a good idea. So maybe we could shift this one later on this process or just forget about it. Then we have keep the plugin list up to date when building the Docker image. It sounded like it was kind of urgent for me because we told that earlier in the meeting when the end user start the tutorial. It doesn't want to see any warning any things to do it doesn't want to have to update the plugins. It wants just to deep dive into yeah the tutorial doesn't want to know about the plugins and so on not yet. So that's why I chose this one and frankly first timing I've been more or less doing it by hand. Say more or less because I have a script but it's not yet linked to GitHub actions or Jenkins itself so that's why I say manually. So I've been doing a few pull requests recently to try to keep the plugins up to date and you may have seen in the repo that the list of plugins is not the short list of plugins we used to have. Now we have the whole big list of plugins even the one we didn't know about this is the list of plugins that were installed by default by Jenkins. And we have to keep it updated the whole list updated because if we only update the set of plugins we are interested in. The end user will have the warning in the UI when first starting which is not what we want and that's why it's in the week 31. Um, what else do not build the image. Don't remember the yes go ahead. I will have to drop need to prepare for another meeting. So I'm sorry. You don't have to that's fine with you. You'll keep me posted. We talked to each other tomorrow morning right. Yeah. Thank you. Just checking who is the. I am. The meeting organizer. I think I am. You can leave and it won't shut off the meeting. Thanks for doing that. Yeah, thank you. No. No, you're still there. Okay, so this one is a second part of the docker build and push image because for the time being we are building locally on the end user computer or on github. So the first step for this week is to build and push images to the docker hub. Okay, but then we'll have to use these images within our scripts or docker compost. So that's the second part of the job is week 31. Okay, for everyone. So do you want to postpone some of them can sell or yeah postpone console and put some in this week because we already kind of busy. If we complete everything from this week, then we can add. You're ambitious. I like that. Okay. Why not. Yes, feel free to start something else if you're done with all the tasks from this week. I would like to see that. Okay. I also want to talk about this. I'll get about 510. Okay, let's go. So once more. It's not from the top of my head. It's after having a discussion with Damian. I think. And because, yeah, freestyle. Maybe, Stefan, you know better than I, but freestyle is kind of old, very old and not recommended anymore. Tell you the truth. We only use multiple pipeline. So yeah, pipelines are kind of cool. But frankly, in my daily job, I don't use them. It's not powerful enough. Of course, as we are using github githlab and so on. We need to have multi branch PRs, multi branch, sorry, pipelines, because we are working on server branch. You also do it. We're doing some PRs, some reviews and so on. And frankly, having the jobs created automatically when you create a new branch or you create or receive a PR. Yeah, what else? Frankly. So I'd like that we move all the tutorials to multi branch pipeline. So what was not clear for you, Ashutosh? I didn't understand the difference between why we are doing that. So I've got to know that the pipelines are not used. Multi branch pipelines are preferred. And I think it's not that much. I could be wrong once again. But if I remember well, in the config.xml file that defines a job, there is just a property that is the kind of job. And it's just a different value for the property and you're good to go. I think you could do maybe better by changing other things here and there. But frankly, just changing that and starting the process should do the trick. Maybe. I'm not so sure the automatic scan of all the PRs and branches will be done. Maybe that will be everything. Everything can be a config. Everything is configurable. How deep what you you can exclude you can include. There is tons of configuration on that. Cool. And you can say no to trigger a re-scan. We had to do that for Sage Jenkins because there were so many branch that each time we changed a value, it was re-scanning everything and you were killing the VM. So we had to fine tune all the configuration. That's really huge. You can do whatever you want. That's good to know. Would you have any link? Maybe not now, but later in the process, would you have any link to share where we could see an example of your team? Jekask, if it's available. Yeah, that's probably Jekask somewhere. Yes. I can try to find that out. I did that with Damien and I kind of remember, but I had three weeks of holidays. Of course. Brand was warm up my brain. Even the weekend does that for me. Yeah, but that's the bike fault, of course. Yeah, indeed. Thank you, Stefan. Any other question, Ashutosh? No, that's it. Cool. So if this week at school, any special do you have more things like? This week is probably, I can take, I will take two days that are not important. So I will only go for two days this week. Cool. You have only two days of school today. To this week. This week. Yeah. Yeah. Four days, but the two days are not important. So there is no important lecture. I didn't hear anything. Okay. You choose where you go. Yes. I hope your parents don't watch these videos. Okay. Did you discover anything exciting last week at school? Oh, not yet. You know, any other language framework methodology, whatever, not yet. No, not yet. It will come. I usually, I usually learn that from the internet, because it's more like hands on work on the school day only. Mainly it's theoretically, I am not really good with lectures. If I don't do it myself, I don't get it that much. You have to experiment, get your hands dirty. Okay. Yes. That's the best way. I guess so. I won't show you my hand, but yeah. Anything else? No, that's it. Okay. No. Stéphane. Let me think. No, that was very useful for me. Thank you. Really? Oh, thank you. That's another way of running a visual and how to handle people around. So that's not the way we're used to. So it's very interesting. You did a good job. Oh, really? You don't even see that, but you did a good job. No. You're so kind, Stéphane. Well, you should go on holiday more often. You mean that before my holiday wasn't good enough for you? Just kidding. You were that much nicer. I would do my best to be way better every day. I was just kidding. You were just perfect before leaving and perfect once you came back. Anyhow, it was a joy to have all of you today and let's call it a wrap-up. We'll finish. And the video should be available from 24 to 48 hours. And we'll see each other next week, hopefully. If you have any questions, doubt, whatever, we have the GitHub issues. The GitHub channel and of course the mail just in case all of these wouldn't work anymore. So don't hesitate and please commit and push regularly, even if that does not work. Of course. You have to follow your job. Yes, it's easy. Yeah. Thanks a lot, folks. Thank you. Bye-bye. Good end of the day. Bye-bye.


Hi. So we are the calendar guys. So this year particularly has been quite a successful year for calendar because we really up the notch, we rewrote the entire calendar, we finally finished the rewrite of the calendar. And it's I think a pretty stable rewrite. We have issues which have dropped from the original repository. And yeah, a lot of people have started to contribute to it as well.  The design part, it's pretty awesome. It's more seamless. It's more very much close to files so that the user experience throughout the own cloud stays pretty consistent with each other. The use think like the sidebars and everything which files also use. And yeah, there's nothing new. It all looks like next cloud. So yes, compared to the old app, we use new technologies. So we rely mostly on JavaScript and Angular, while the old app was mostly written in PHP. You can also see this in this comparison. So GitHub always shows you what languages you use in your repository. So on the left side, we have the old repository with mostly PHP code. And well, that PHP code was not the best one. And the right side, we have mostly JavaScript. So now you see that most of the app is running in your browser and it's not so many server-side anymore. So yes, various benefits of the old app. One of the biggest one is performance. It's much faster. Previously, we generated a lot of dialogues on the server. So it meant that your client had to send a request to the server. There the dialogue was built within them with the values. And then it was returned to your browser. Now we build all the dialogues in JavaScript, which is obviously much faster. We also have, like, public sharing coming up. We have web call. We have support for attendees and alerts. We have a higher code quality. And also, weak numbers and a better user experience. Yes, about web call and web call features. So you can, like, include ICS files from the web in your private calendar. So you can see in this screenshot, I'm including my Facebook calendar. I can see that the next conference is going on right now. And I can also, I also included the web call feed of the local hackerspace. So there was an IPv6 talk at the beginning of the month, for example. And we just merged this branch two days ago. So I'm very happy to announce that this feature will be released this weekend in version 1.4. And the next big thing that's coming up is calendar publishing or public sharing. That was implemented by TCIT World. I'm afraid he's not here, but please give it up. I'm pretty sure he will watch the video. Yes, this basically allows you to share calendar publicly and to people see a similar view so they can look at it in the browser or they can also subscribe to it in a web call client or ordinary calendar clients.  So right now we try to release a new version every month. So next month we aim to implement search and undo actions. Afterwards we want an advanced editor for repeating events. In 1.7 we finally want to display events alarms so you actually get an alert when an event is coming up soon. In 1.8 we are planning free busy support so when you schedule an event and you invite other attendees you can see when they are free. And yes in 1.9 there are no bigger features yet but you're welcome to send us feature requests and we will consider them. So yes we are next cloud dash calendar or IRC. You can find both of us there. Our names are IRCnext and yeah that's pretty much it.