 Hi, everybody. So welcome for this new Jenkins infrastructure meeting. The main thing that I would like to talk now, and Jeff joined the meeting, meaning for that, is now that you have a code signing certificate for Jenkins core releases. He was interested to see if we could also sign components, not just Jenkins core releases, but also components like remoteing, which, personally, I think would be a really good idea. The thing is now it brings a specific challenge, like, should we, I mean, specific technical challenges, but like, should we reuse the release at CI to Jenkins environments to sign those components? Should we allow maintainers to trigger jobs on that machine? Should we deploy something else? So I just created this morning a specific ticket for this, which is, where is that? Infra 2619. I don't know if you have, I think we'll have to continue the discussion on the meeting, but I don't know if you already have any inputs or ideas or opinion on this. So for me, I like the idea, and would defer it completely, defer any implementation on it, at least from you, Olivier, or from me, or even from potentially Tim, until after we get security and LTS releases under control and resolve for core release automation. Concept sounds good, but the schedule-wise, I would rather not distract us at all. So from a scheduled point of view, when is the next time, Jeff, when do you need to renew the code sign certificate for the trees? I'll follow you. That's the one concern of the schedule from the remoting side, is that I've been purchasing an individual code signing certificate for remoting. And it expires here really soon now. So it's, I think, exactly June 12th or 10th. I could look it up. It's right about then. Now, I don't have any current plans for a remoting release at the moment. So it's not like I have to have something immediately. But there's a big hope of not having to purchase another code signing one for anything that, individual code signing certificate for anything that might come up for yet another year. Yes. So my argument is the $500 should be reimbursed to you by the Jenkins project. And it's cheaper for us to do that than to risk trying to accelerate the delivery of the core release automation capability. And if we derail core release automation, that has a much bigger impact than if we spend $500 of Jenkins project money. I'm just wondering, is it enough to just use them having a release plugin for it? Because then we can reuse most of the process that we already have for the weekly releases. We don't have to add in specific parameters or whatever. How do you release the remoting? Jeff, is it Maven release, prepare, and perform? Yeah, that's all I do. I have a profile that I, two of them that I use myself that contains the GPG signing key and the code signing certificate information. And then I just do Maven release, prepare, perform, and just do it. It's really pretty easy. So no, but you are having to answer the interactive prompts for release, prepare, release, perform, or have you gotten past any interactive prompts having to be answered? I've never, I do answer the interactive prompts. And so, I mean, the part of it that I know Olivia, and I talked about a little bit, is how do we know when to trigger one of these. And then we'd have to set it up to be like a default answer to the interactive prompts or something like that. I was just wondering on the triggering of this, couldn't we just have a different folder in the release.ci and then put some folder authorization on and allow access to the maintenance of the remoting? So I think the reason why I would not feel that that would not specifically like the idea of letting more access to that specific machine is because then we'll have to maintain our permission to release the CI-D Jenkins.io. So I was just more thinking maybe to have something like a front-task that triggered Java or maybe once we merge to master, we just automate the deployment. The thing is for now, I think because it's only one component, it's fine to just, let's have me or whoever to trigger that thing, but more globally, I feel like we are just opening a door here. And not only Jeff, we want to sign components. Jeff's need is distinct in that he is currently, he's already delivering signed components. There aren't any other plugins that I'm aware of or other components that are delivering signed, except I guess the Windows installer, maybe WinSW, but in general, the Jenkins plugin commonly is not signed, right? Remoting is distinct that way. It does sign and it should. Because then as a first iteration, I'm totally fine to just add a new job, maybe under like a team suggested, like we have a component folder and under that component folder, we just add that new job and that's it and maybe trigger it when we need it. Do you have an idea how often you release it? You're on mute. Jeff, you're muted, Jeff. Or silent if you're not muted, you're silent. Same. You did unmute for half a second and then you're muted. Okay, there we go. Like clicking things so rapidly, not responding, but it couldn't tell what I was doing or I couldn't tell what it was doing either way. Yeah, so typically I only release Remoting like once every few months. When I have something bigger that's going on, sometimes there's a little bit more to do. WebSockets was the most recent significant example of that and it was, there's a little bit going on with that, but it's stabilized. So the only thing I have actually in the queue right now to be concerned about is some work that I had going on that I don't have enough time to finish for a while at least. So it's not terribly common to figure like every couple of months, maybe a release. Yeah, so I don't think it would put too much pressure on us if we just manually trigger the job for now and then we can work on having our automating. It's a wonderful. So Olivier, when you say manually trigger to keep the permission definition simple, it means you or Daniel or Oleg would trigger because you don't intend to grant Jeff permission to release.ci.jankins.io. That's what I mean for now, yeah. Great, okay. And that sounds good to me for clarity. I just wanted to be sure I understood. Great. The thing is if we grant Jeff means that we have to update the configuration of release.ci.jankins.io to have more fine grant control on who can do what. And the other thing that I'm just suggesting here is just like we drop a new job within your Jenkins file for remoting and we just reuse what we have today. And so under the people who can trigger core releases can also trigger remoting. And so we move forward in this way. Great, super. So that's all. Yeah, so if you don't have any other questions, I propose them. And I'm fine with basically any of these proposals that we have here. I mean, I could continue the individual signing certificate though I don't really want to, but the idea of keeping it and then me asking one of the existing maintainers, Daniel, for example, or Olivier to release, I'm fine with that too. Okay, but then I propose to first, I look at, I'll try to reuse what you have today to see if we can reuse that. And so if it doesn't take me too much time, I try to do it as soon as possible. So if it does not work or if I realize that I'm gonna need some much more time, then we investigate other options. Sounds good. It sounds like we have a sufficient set of options and a sufficient understanding to proceed. Yep. So then the next topic with, while you're still speaking about, talking about the release environment, I don't know, Mark, if you had, if you made any progress with testing packages. Did not. I still don't have the pull request ready. So right now it's still me running those tests interactively. Because interactively is such a funny word to say. I edit a line in the file and run the job. Because I've been wondering recently, because I'm having now quite big peer that I would like too much. So for the LTS and the security releases, I'm wondering what would be the best way to have a dev environment where we could validate this kind of work. And I think it could interest you as well, because I would feel more confident to be sure that we don't break the release process, especially for stable and security one. So right now, I try multiple options, but I faced issues because the release environment use specific settings like specific private IPs, like access to VPN access to Azure resources and stuff like that. So I wasn't able to easily test the release process on my machine, but it's something that I'm investigating at the moment. Great, yeah, I'm certainly interested in whatever you learn there, Olivier. Olivier, I apologize. I have to drop off in one or two minutes in order to join a webinar that's about to start. Sure, so I think we cover most of the topic, the most important topic. So I don't know if you have any last minutes that you want to bring in and we want to discuss. Otherwise, I just propose to finish the call here. Well, so I guess I should double check. Has anyone found any negative consequences of the dirty hack that I use that every seven minutes reconnecting the EC2 agents? The hack I suggested last week. What's that? It's the hack I suggested last week. It is exactly the hack you suggested last week. I just couldn't find a way to do it from remote. And so I cheated and do it locally on ci.jenkins.io. And it's exactly what you suggested, Tim. And it works quite well, as far as I can tell. It still leaves me feeling soiled. It still is dirty because it shouldn't have to do, but it's better than me doing it every 10 minutes as a human being. I think for now it's okay, but yeah. It gives everything, right? Right, that was, and it doesn't actually solve the problem, right? It just sometimes we seem to get lucky and hide some problems. That's great. And just, yeah, we just delayed a problem. Right. Which is what we're after, isn't it? We're waiting till we have more time. Right. So, yeah. So I propose a finish meeting here. Thanks for your time and see you on RT. Bye-bye. Bill.