 permission to record. So recording has started. Yeah, awesome. Thanks. Hi, everybody. Welcome for this new Jenkins infrastructure meeting. We are the 29th of June. So we have three topics to cover today. So the first one is we have a security release coming tomorrow. So this will be a weekly release and a stable release. So stay tuned. I mean, I hope that we won't have an issue with the release environment. So everything should be fine by tomorrow. Just, yeah, just related to this, please don't update Jenkins instances tomorrow. So we don't introduce potential noise. So the next topic is about analytics. So giving start a discussion on discourse about how we, I mean, if we could use Cook and Analytics or something else for plugins that Jenkins or IO, we explore two options, plausible and immutable. So the first one we just because I'm already using plausible for personal projects, but I have the smallest subscription. We just did an experiment for plugin sites. So yeah, we just have access to basic information. We just stop the experiment because we consume all my credits in just several hours. And so my account is not big enough to cover plugins such as IO. And so I don't want to pay right now. So without to explore, I just want to be sure that we want to use plausible or matemobile for paying or finding sponsors. So if you have an experience here, that would be that, I mean, if you're free to share, I think the discussion can continue on discourse. It's in the infrag category. And what I like, sorry, yeah, Olivier, what we're seeing here is a is a website website statistics report that was generated for plugins that using plausible. So you registered Jenkins.io with plausible. It started collecting data. And this is this is what you got that quickly. Yes. So it's quite simple because it's just a small JavaScript that you have to share in your websites. And so you don't allow them that small JavaScript send information to plausible. So this view is public. So just go to plausible.io slash plug in searching. You see a small peak because if you just look at what happened since seven days, you have a small peak because given enable that service yesterday, this time and I disabled this morning when I realized that I use 2000 22,000 page views and I have a limit on 10,000. So that's why I disabled it for now. But you had a kind of information that we have this page visited sources countries. So it's really basic information. It's not the kind of information that gave in was looking for because giving was more interested about understanding the behavior of users on the website. We could use Google Analytics, but I would like to avoid if possible. So I think that giving as an action attempt to explore Matomoto, which is another option here, but I don't have any experience with this one Matomo sounds more like Google Analytics replacement. So yeah, if you have any insights, feel free to share my only concern. So yeah, in both cases, plausible and Matomo are open source. So we could deploy the services ourselves. But my concern is in first that kind of service, you know, they're to have them useful for the project, you want to create data on a long term. And so that means that we will have to be sure that we we have to be sure that we back up data. And so that would just put extra pressure on the Jenkins software team. And we already have a lot of things to do. So that's why I'm not really confident to host the service ourselves. And also more importantly, as soon as you provide a service with analytics, if the data are incomplete, people take the wrong decision. I mean, people take the wrong conclusion based on the data. So I'm always feeling uncomfortable if I cannot share a service that it's 100% reliable, when you want to collect data and analyze them. So that's why I'm the tree. Yeah, I would like to do it to explore the sponsoring or the beta approach. So that's a small project. Another, the next topic is about migrating archive to Jenkins.io. So we discovered last week that Rackspace stopped sponsoring the project two months ago. And so now we receive invoices. Those invoices were sent to KK's email address. And if I get to share them with us, so we'll have to pay the invoices. So at the moment is around 600 per month. So we have to pay and we have a third coming. So the idea is to migrate as soon as possible. So we are now exploring. So archive is a copy of another machine. So we could deploy that on Amazon, but I would like to have it deployed on another cloud provider. So we have some redundancy there. So we have either the option to deploy in Azure, but we are already trying to decrease the cost of our Azure accounts. So I would like to do that option. And so we have two options here, either deploying that on our Oracle clouds or on Scaleway. I mean, those two accounts offers low cost infrastructure. So that's what we are exploring right now, because Devian is not available at the moment and he has access to the Scaleway because that's a new project that we are exploring there. And we'd be more interested to look at Oracle this week. But yeah, migrating archives at Jenkins.io to a different location is quite simple, because that machine is perpetized. So we just have to be sure that the data is transferred from one location to the other one, which is the one time our sync commands. So that's the current state for archive. Otherwise, I don't really have any other topic. Last week was pretty busy with Silicon and Contributo Summit. So we reduce our time here during that time. So do you want to break any topic? Mark. So Aditya had paired with Damian on some efforts last week. You and I have a plan to do work on archives.jankens.io. Are there sensitive things there that we could we offer to let Aditya pair with us as well on that one? There is nothing critical. I mean, we don't have secrets, I would say. So we won't share a secret in the video. So I mean, everybody is free to join. After the budget. So Aditya, if you're interested, I'll include you in the invitation for our session tomorrow. I think it will be more difficult. Yeah, no, yeah. No, maybe that's possible. Sorry, what do you think may be more difficult? No, I was just thinking in time, but at the time it's fine for Aditya, I think. Oh, well, it's as bad as this one. It's a terrible time for Aditya because it's late in his evening. But it will be right now, Aditya, your time, I assume it's roughly 10 p.m. 10.30 p.m. No, it's roughly 9.30 p.m. Okay, so it would be about 7.30 p.m. tomorrow, your time that we would be. I'll include you on the invitation. You're welcome to attend. If you can't attend, don't worry. That's perfectly okay if you're not available. Just for me, it's great to have other people involved as we're doing these things to help us and assess what we're doing. Just for information, if you want to move it later, feel free to ask and we'll see if we can do that. I think I will be available, so yeah, I would be happy to join. Okay, great. Is it okay if I suggest something? Can we please go back to the docs, actually? Sure. So, when you brought up the topic for plausible and Matomo, you were referring that someone, I forgot the name, actually, they were looking for something like user analytics and user behavior. And we would like to avoid Google analytics. So there's this another tool I'm aware of that's called awstart. If you want to again link, they'll give you the link as well. Yes, I'm putting the link in the chat. Only bad part about it, I see is that UI is very old fashion. So the UI part is not great, but it gives a lot of data about number of visitors, unique visitors, their duration, and rush hours and etc. So that might be something interesting for someone to look into. And I think it was open source, so we can build on it as well. Interesting. Thanks for sharing. I was not aware of that too. Sure. I look at it. I was not aware. Thanks for sharing. There is one last topic that I can bring. I'm not sure if I shared that information during the last infrastructure meeting, but I made some changes to the status page. So I'm going to share them again. Sorry if I shared them two weeks ago. So what I changed in the status page is I removed all the iframe. So it's way faster now to display this page when you go to status. But instead, what I did is I added two different tabs. The first one is services. And so if you click on it, you have, because I'm in a dark mode, you don't see the link correctly. But at the moment, we list three services, and the plan is to add more. So we just have to work on the documentation. But if you click on a specific get-a-jink, and let's get-a-jink scenario, we now have access to a description of the service. The iframe is loaded here. Because we only load one iframe, it's just faster. We don't have to wait five minutes to load the full page. And then we put some links to various locations. So in this case, it's get-a-jink-in-zalio. So I'm providing links to the ham charts, to the service, and so on. And so if you're curious about what this look page looks like, you just go to the get-repeatory status page. So you go to the content, services, let's say get-a-jink-in-zalio. Let's show the review. And it's just an ad hoc file with a few parameters. So we just provide a parameter to the file, and that will render. So we have the title of the service. You have description, the monitor views, if you want to let's say include an iframe. So we have a title for the iframe, and so on. So we use the Go templating to generate the page. And so the plan is to add more. So we have right now one for get-a-jink-in-zalio. And the idea is to provide, let's say, for the main website, jink-in-zalio, plugins, and so on. So that's how it changes the status page. I'm currently working on upgrading CS states. So it just changed the way we visualize we have access to the time. And that should clarify. And so if I go back to the root of the service, I also provided another view, which is monitoring information. And so from here, we also have links to other pages. And so, for instance, there is links now to Datadoc directly. So there is one view for every website response time, HTTP response time. And so the plan is to just provide the links to the different public dashboard that we have on Datadoc, PedroDuty, or whatever. I'm just trying to revisit how we deploy and manage the status page. I know that we are putting a lot more information about the different services on the status page, because, yeah, the goal of a status page is just to tell you if a service is done or not. The goal here is, my goal here is to provide enough information for every services so people can look into the different location, understand what's wrong, and maybe provide some, yeah, understand what's wrong, basically. So right now we only have to get the Jenkins that I own, package the Jenkins that I owe, and update the Jenkins that I owe. But the plan is to get, so it has to have more. That was the last point. Any other suggestions? Otherwise, I propose that we close the meeting here. None from me. Thanks for showing status.Jenkins.io and marvelous work. I love it. Yeah, I'm really happy with that. So that's working very well. So then thanks for your time, everybody, and I'll see you tomorrow during the work with archeology.Jenkins.io and otherwise, see you on our scene. Goodbye. Thanks. Bye-bye. Thank you.