 All right, Baptiste, let's get this meeting started. And yes, please share your screen. Yes, so hello, everyone. So this is the weekly meeting for Jenkins Essentials Open Planning. So we're going to discuss the status of the project. So who is present? So Jenkins, Tyler, Jesse, Oleg. I'm not sure who is going to join. So let's just head over the statuses. So Tyler, maybe you want to get started? Yeah, so I made a significant amount of progress last week on the delivery of updates using a stubbed-out update manifest. As Baptiste and I were discussing a little bit in chat, I've been having some difficulty with the integration tests. But as it stands right now, the two things that are outstanding for that pull request, that is pull request 70, the integration tests I have to have to work, obviously, before we merge anything. And then I have one more, let's say, test case to add. And that is, right now, the update level is not being stored for anything. And so if you turn the Evergreen client off and bring it back on, it will just redownload everything. So the client side isn't doing the update level check just yet. That's fairly straightforward, but I can't really, I can't do that successfully until I get the integration tests, actually, to cooperate. But it's looking promising. Yes. I guess the next thing for the week would be to get some stuff deployed. Yeah. Sorry to go ahead, Baptiste. No, no, no, I was just agreeing and saying, yeah, from what I could tell in your PR, indeed, there's probably only left something like, because you've already written the war and plugins download, so now we need to say, OK, please, SupervisorD, restart Jenkins so it should work. And so, yeah, it's looking very promising. Yeah. Unfortunately, I'm at Microsoft Build most of the week. So I'm going to try to hammer in some changes in between talking to people about Azure and Jenkins and things like that. But what I'm hoping we can start this week is some of the infrastructure planning. And I haven't had a chance to look through your meeting notes on discussing some of the logs with Olivier, which I'm assuming has happened already. Yeah. It was my good morning. Getting to a place to where we can actually provision evergreen.jenkins.io or start to this week is something really interesting. Yeah, indeed. So go ahead. No, no, do you want to discuss other things in flight or are you just thinking is your status done? I don't hear anything if you're talking. For people listening, Tyler was saying that he would be on a not very good connection. So maybe I don't know if it's me or. I can't hear you. You can hear me. So I guess it's Tyler. So he did send the warning that it would be not a great connection. So yeah, let's just switch to you, Raoul, since you joined. So let's just give your status with regard to essentials. Add networks. Go ahead. Yeah. So not a lot of work for essentials. This week I've been firefighting on other sites. Regarding the kit plug in the ATH and PCT, which is already running on peer-required basis, it's working, but now we have detected some instability on the plug-in runs. So Mark is going to do some changes regarding the parent pump versions and things like that. And after that, he has requested me to help in case there are some problems with PCT or ATH, which is something that I'm going to do. I'm very used to peer with ATH or PCT. So that is what I'm going to do, probably. This is regarding those two issues. And after that, I'm going to start with all the great work on the custom work package and improve the flow on the plug-in. The ticket is not yet there, but it's created and it's on. By the way, I've got approvals to publish my pipeline library sources for my custom work package. So hopefully it will be something like online integration for you. Yeah, I know that will be great. If I'm lucky, it will be published today. Yeah, great. Cool. Anything else? By the way, the thing about the custom work package is not here. So is this unproposed? Or not my stone one maybe? It's not there because it wasn't intended for my stone one, but I'm going to add that here. Great. Anything else? Not sorry for being on so many fronts. Sorry for that. Thank you. I think I'm going to ask, even if there's no really something here, but I guess Oleg, you can go on if you have something to say about that. Well, I do not have specific updates for essentials, but I have updates for related things like a bill of materials. So one of good news is that we have reference documentation for bill of materials and custom work packages, which supports both inputs and outputs. I have integrated this poll request today, and I will be setting up pipeline tools so that we can relate it in our flows for testing purposes. I've placed it down into the chat. Okay. So it relates to the PR from Carlos in flight right now. Great. Okay, great. By the way, Taylor, I was going to say, Jesse, do you have any feedback from Carlos? Is he going to finish this PR? I guess I haven't. He's been traveling, so I haven't heard much from him recently. I hope they'll have time to work on that this week. Main status for me is I have a tool in progress, which looks for the most recent applicable incremental or other version of a given artifact. And initially I have it set up as a Maven plugin to do a palm update similar to the versions to various mojo's in the versions Maven plugin. And it turns like we now have a concrete YAML format from Custom War Packager that I could use to prototype a similar change in that format as well. Do you need this model to be decoupled to a separate library or you are fine with the current state format? That's fine. I mean, it's just all I would be doing is changing the version attribute, I suppose. I just need a working concrete example of a file to patch. And I think since last week for people possibly watching now or later, Jesse, you're kind of talking about what you did like Friday or something, but you did a lot since last Monday I think, whether you're doing incremental and checking and so now it's kind of working and merging the core and so on. Yes, it is in core. So any core pull request you file, it should be deployed automatically if all goes well. The way the new fall broke at the repository after the weekly on Sunday. Yeah, I already filed a fix for that already. So that's great because for outsiders, I would say, you would see that indeed now even the core is deployed automatically for each PR that gets merged. So that's great. And that just works for everything, not only the Jenkins war. It works now already for some plugins, the ones who have been configured to check those things. So that's great. Yeah, once Jesse finishes his tool, I will be setting up a prototype for Jenkins Docker image, which will be picking the last version of Jenkins core and maybe some components like remote. So that we will have a boilerplate Docker image. Yeah. Yeah. It would be useful at some point to set up incremental builds for remote angles. I haven't tried it yet. I have created a task for remote in constepler. So for remote in itself, it's going to be a problem now because pull request builder is broken so that you can't really rely on correct publishing. And for stepler, I think we can do that. But yeah, I haven't got to it yet. I mean, we have the main issue of stapler is we need to copy and paste a bunch of stuff because it's not using a Jenkins poem. Well, let's make it using Jenkins poem. Yeah, put it. Actually, I thought that I've modified stuff to use Jenkins poem. About that. Maybe it's slightly off getting off the topic for today but didn't we have some tasks somewhere about at some point moving stapler and dirty Jenkins here or is this not even a subject? Yeah. There is a task to do that somewhere. Make this kind of thing a little bit easier. Okay. I guess anyway we are going slightly off track. So let's get try to, or if you think something is really, really essential, you can obviously talk about this, but I think we just affect the ease of doing things like pushing small changes from remoting or stapler into evergreen production without having to do a full release and so on. I guess it makes more sense, by the way, for remoting than for stapler or maybe not because well, yeah, no, because I mean it's included anyway in the core so it needs a PR in the core to be picked, right? Not exactly. If you use customer or whatever. But for deployment evergreen, yes, there would be a matching core PR to pick up that version. But the point is that if we used incremental versions for remoting and stapler repositories then we had them being built properly then it would be easy to do that and get that going live in a matter of hours without having that happen. Instead of waiting to wait for someone to release a version of stapler. Right. Actually, we can do it even without incremental releases if you are fine with the fact that it goes from master branch. Okay. Or if I have a demo which does that, but yeah, it's kind of risky. My point is that, well, it makes a lot of sense, but I'm not absolutely sure this is the most urgent thing to do. But at the same time, it kind of tests the incremental story as a whole. But yeah, I think it could be postponed to my soul, two or three, because anyway, we would need to find something like a PR in the core and that part we would really deploy. So yeah, anyway. Thanks everyone. Let's... Yeah. Quick comment now you talk about incremental. Just would like to ask what do you think about using the ATH itself and the incrementals? I mean, at this moment, we are using a concrete commit on the metadata files to run in ATH and that commit has to be updated regularly. So I think it makes sense to use the incremental system to... I'm not sure because right now do we really run a given version of... It's not like we're using a release of ATH. We use the master branch, isn't it? Yeah, it's true. We use... So it's not really... It's not a Maven artifact. Yeah, so does it really... Do we really need that, Raoul? Because by that I mean, we already run the latest tip of ATH, don't we? We have the possibility to run master of ATH, yeah. But that is something that we have probably discussed. It's not ideal because you are not having a deterministic commit and that kind of thing. So... Yes. But I mean, you would point to some SHA, right? Anyway, if we use incrementals, you would have to use PR to update the SHA to some other value. So I'm not absolutely sure in that very case, incrementals offers a big difference for ATH by itself. No, we can't use it for ATH because again, we don't pick up a Maven artifact for ATH. What maybe you would like to do, Raoul, for ATH is automatically maybe file a PR on the core or something like this to test when there is a new commit, when we detect that the SHA being pointed to for the version of ATH on the core, there's some new version of, you know, some new SHA for the latest tip of ATH, then file automatically PR to test if ATH is as stable as before and then, you know, bump that version so that everything uses the latest of ATH. Yeah, that makes sense. So you want campaigners to be able to follow it? Sorry? So you want continuous delivery for tooling? Yeah, I guess you would like to make use of the latest as recent as possible version of ATH constantly, I guess. Yeah. Yeah, in practice, acceptance tests pretty frequently break for kind of silly reasons. Like somebody, you know, somebody makes this slight change to the format of a config Dutch Elliott and some plugin and then the selector doesn't match anymore. And so if you look through ATH history, we have a lot of places where it's doing like this long, if then switch where it's trying to deal with two or three different versions of the same config file, which are the same config screen, which is hard to maintain. So it would be nice to just be able to say, you know, this is the version of the test that I'm using. This is the version of the plugin that I'm testing. If you change the plugin format, well, okay, you can make a change to the test too and you can pick those both up in one commit. So you don't have to try to, you don't have to have these, you know, untested combinations of new ATH with old plugin or vice versa like we have today. Like we have, you know, for example, for testing LTS versions. My main concern here is that matching Git plugin making some changes on the user interface that is going to break the ATH for the rest of plugins. So typically in this flow, the maintainer of Git plugin is going to also commit the changes to the ATH to fix the test. And we need a way to make those fixes accessible for the rest of the people running the ATH. I see, I don't see a good solution. Can you, can you possibly, Raoul, Fai, Jira summarizing your rationale, your concerns and everything so that we can all understand it and dig into it possibly and maybe have a better understanding of and possibly the, I mean, the possible solutions you would have in mind and so on so that we can work on this and decide if it needs to be fixed like next week or next year. Yeah, yeah, makes sense. Right. So we have a bit less, a bit more than 10 minutes left. Don't think I gave my own status so I'm going to do that pretty quickly. So last week main thing was to basically work on the whole error telemetry story. So now the JetPop for the client side was merged a bit before. I've been writing some Node.js code and now we have the full story running, I would say, as a prototype. So we have Jenkins that is so writing logs in JSON format as per the JEP 304 I think on the disk and then the Evergreen client is reading those and pushing those into the backend of Evergreen so the backend that will in the future be deployed behind something like Evergreen.jenkins.io or something and now I'm writing the JEP for actually gathering feedback and so on because I've already a prototype for this but what will the API for pushing those logs look like for real? And I'm almost hopefully done. I was writing in that a bit earlier. So I hope to be able to submit that today later hopefully and I'm out tomorrow so I would like to try and submit that for feedback for today to save some latency. Is there any question about those things in general? Let me see. And also with regard to what Tyler was saying a bit earlier about the infrastructure, the Jenkins infrastructure and running thing, exactly. So Tyler is asking me for exactly the thing I was going to say so that's great. We are in sync. This morning I met Olivier Verlin, so one guy the guy that is working with Central Tyler on the Jenkins infrastructure and so we had a talk dedicated to how now there's services available and the setup available to handle the logging for services running in the Kubernetes cluster because for people not knowing about that so now the Jenkins infrastructure is I'm not sure how much but mostly running in a global Kubernetes cluster running in Azure so this is very, very likely that we will want to run the services for Evergreen, for Essentials in that cluster so that's why we were discussing how those things are set up right now so that we don't do things in a bad way. So for people interested as always as we are following the four opens, we have docs meetings and so I put a small summary here about what we discussed this morning and basically I think it's likely to be that the backend service that will receive the log and will push those in fluently that is already an existing component in the Kubernetes infrastructure for Jenkins and so then we will have those logs probably push in the Azure log let me see Azure Log Analytics probably at least in the short term but from an Essentials client I would say client initiative I guess it's not a big deal because the most urgent thing I would say is more to design how the endpoint will look like so that the instance around the world can push the logs and then if we change things behind then it shouldn't have an impact so that's why it's kind of more urgent so that we can actually have actual Essentials instances running and then possibly finish or adjust or change things in the back I hope it's slightly clear at least I guess we are mostly done everybody gave his status anything else for by everyone before we close Tyler I guess you're in crappy so I guess Tyler has nothing more to say Jesse, Oleg, Rao great so see you next week everyone bye bye