 So it looks like there's a public holiday in France, so a few people might not join us Is it not a public holiday in Switzerland as well as France? Well, it's a holiday for most everybody accepting my company And they share my screen It's running a little behind schedule So Batiste is out so Batiste and I don't really have Stuff that we can discuss if he's not here and so I'll have to catch up with him tomorrow on some of the the error telemetry stuff I Just wanted to give a quick update on my side Just say I know I'm behind on I'm giving you an example, you know YAML this prototype Output format that's on my plate today now that I'm finally back at the office Yeah, well, I mean I've moved on to other things anyway, so okay Would be nice to see it anyway because we've had some related stories From Okay So Jesse is to be you've you've got other stuff on your plate this week Do we have any essential stuff that we should discuss? I mean nothing for me. Okay Well, they're things that um If aside from from this ticket, which we have some we might have some overlap on And Whether I don't see things here that are related to other things that I should be in keep in mind when Batiste and I get started tomorrow Well, I haven't put the related stories Essentials But the one thing which is related is acceptance that harness patches being done by Ravu So I mean opportunity to reload each of each plugin solution So this is one thing which would be really helpful because currently the break the essential in many cases And I also have an action item on my side to improve packaging for the core because There are issues with Cluster loading when you're on the current core in Harnet, so I will be able to build into the portion set of patch in the jar I hope the delivery it may be a few weeks, but the existing full request should work fine even with the current state of CBP Gotcha. Okay So the acceptance test harness stuff Did like is that causing Um Those outstanding patches are those causing failures and see it at Jenkins IO or are they just something that you enroll noticed That still needed to be done So the problem is Installation flow so in a case you can say that a particular play test requires a plug into being full the issue because Custom work packages may already produce a work file which bundles to this plugin and it means that if you install a newer version Just due to dependency or whatever you need to reload the Jenkins. Otherwise, it won't work And although ETH itself has logic, which allows to implement that Integration in pipeline library in order to enforce to this logic by default Okay So it's just a small matter of programming Yeah, were you ping me with the M that and the JTH Tickets once you got them. I just want to make sure I'm keeping an eye on I Don't think it's gonna block anything I'm doing this week though Yeah for sure. So yeah, we'll check the tickets and mean for them to the dashboard Okay, that'd be really helpful And raw you had you'd created a whole bunch of tickets. Yeah Can you hear me yes, we can okay, so basically for the quality bar I have the impression that you and that these have the eight was like a This coverage thing or something like that is a little bit more So it's just a list of tasks That need to be done Before saying okay, it's safe to release. So I have created a draft for that and I have created Pickets for every task there and a witty page that the list all of them. So you can have a very quick Intro to the current status and all the tickets you are seeing the are Related to one of the tasks in the quality that I have created. So I'm not sure to which one as I'm those tasks at this moment I think this is something to decide and I am not also not sure about the teaming. There are three tasks that I Understand are a mandatory and others that are good to have So That is a reason I have created all these tickets. I have put them on my stone one Paul just to have feasibility today. So we can discuss them if you want But I just need to triage these Yeah, okay Yeah, okay. I can go through that after the call then Why is this one green? Maybe some of them are already Done if that is a the case we can just mark up don't know to pick eight put the proper link on the quality bar and go ahead When you say quality bar, is this a wiki page you have somewhere? Yeah, it's on the Let me share with you It's on the wiki page. I think I see it and get her It's linked it on the ticket This guy Let me see. Yeah, that one So that is a draft of a quality bar the same way we have been doing and That as you can see the tasks are more like generating things and the ticket are just to track the the progress of them so take a look through each the tickets and And okay, if any feedback you may want all of these is obviously open to discussion and Just take a look okay, I think I'll definitely be getting to this today And just given that you're a few hours ahead of me. We might just have to talk about this tomorrow morning Yeah, we can talk tomorrow morning. No problem Okay, it would be interesting to have but is here. Yeah, I Have as you can see I have assigned Some people to the most half ones and for the other is to be decide because They are not so urgent Yeah May is apparently a month filled with holidays in France but he's warned me about that and in April So yeah, we'll probably I'll just ping you on get her tomorrow We might just need to jump in a hangout really quick once but he's just back and we can we can talk about this I'll do a first-level triage of some of this stuff I Think but he's and I will have to have a debate on what counts as a P1 Yeah, but we need that at least because That is the first thing we can just go to code coverage without knowing What is the body minimum we need? Zero I'm not sure if you've been following a Thread that got much larger than I anticipated that I had started on the Jenkins dev list around Versioning configuration as code schemas You know, okay So All again, I sort of briefly mentioned it and get her just before this but the The biggest concern that I have and just to give you a summary of thread is I was Thinking about backwards compatibility of the configuration is code YAML that we rely on And How we would know from one version of a plug-in or another where there are configuration fields We're still applicable and still valid and so I don't know if this is the opinion of one of the developers But they're not I agree with it that You just need to test this before you do any upgrades no problem So I'm not sure if this is an if I have a configuration setting that says, you know The met like right now we have one that says the metrics URL for the metrics plug-in should be this, you know HTTP example.com blah blah blah a lot, right? And With those sorts of configurations, I'm not sure if there's a good way that we have for testing that except for the accepted test harness Tooling and I wanted to ask you if there is something that you had a better idea of how we would test that our configuration is being correctly applied Do you plan to allow users of urgent essentials to Do their own configuration? Because if you do then you get into a chicken and egg problem that's To me that's far less my concern I mean, there's nothing I can do that right now that would prevent somebody from being able to use configuration as code Because we're using it Yeah, so I just apply the I Mean just make sure that whatever process applies the configuration Happens before the health check complete, right? Yeah, if it's out Don't upgrade I'm going to to take a look at the Bread I'm thinking how do I I'm sure do the agree with yes it here We need to do that check Before the date it I think it's easy to check on Not be on a pure request basis We can use the custom work package and try to to be worse and after that run 88 or or even PCT Because now we can use a custom word for the jth So that is another way of testing Yeah, but it doesn't The problem of course, okay, you just cover comes a compatibility show what you're going to do for example we have a security release and The only thing we know after running spot checks with the security release can it be our flight to the Jenkins? instance so what I'm what I'm most interested in is Where where we can apply the easiest level of testing Just because I think Like if if we're relying on health checks That's a little bit further away from the developer making the change I guess then then I would like But HCH is really really heavyweight and I understand that It is I wanted to sort of defer to you role for where we could Where we could add testing to make sure that our configs are correct Yeah, I'm going to think about that. I'm going to create one ticket for for that time Just so you're going to say yeah, I mean again it depends on Whether you're Considering user configurations only things that are baked into the essentials itself But in general, I think we'll assume that users will have their own declarative configurations in place And We can't know exactly what they might have configured and they might have configured fairly exotic features and Plugins we don't pay that much attention to so I Think we just need to it seems most straightforward just to include this as part of a health check although I mean we can also You know have static analysis kinds of tests that cover Very central configuration, I suppose They generate like we could generate an example configuration using Some earlier snapshot and then you know check whether it still applies after some update or something if we see problems Yes Understanding this configuration is going to be on the Instances that are going to be updated so every instance can has different configurations So we're gonna have We'll have the the primary configuration, which will be the same for every instance provided by Jenkins essentials Right, but there may be as Oleg is pointing out users may also add their own YAML based configuration I'm less concerned about that because it's sort of a Right now. There's no users first of all But there's it's sort of you know infinite possibility there Yeah, so it's not maintainable from our point of view. Yeah, the basic configuration is something we could test Yeah, yeah No, no, I have a clear understanding And one of the follow-up tasks would be whatever you do for testing in Jenkins essentials flow it may make sense to contact the security team and to discuss how We would test the essentials for security Releases Issues that don't appear when we ship the LTS We need to know about potential integration issues in advance Essentials users are not left behind if there is a compatibility issue Daniel and I have discussed this a little bit, but we haven't set out a plan yet just because We both have busy doing other things Yeah, I just went to I just wanted to point out that configuration is code plug-in Skips over in applicable configuration sections, but logs are warning about them to the system log Then we don't need to do any custom development for this. It would just show up from a completely generic test that asserts that a stock Essentials instance starts up without warnings and same for the upgrade check if your upgrade check says Warnings force us to Cancel the upgrade then that handles Your current the configuration is called engine is not flexible enough If you add an optional In all-style way way, so you have a data bound constructed You're the new You Create a new one so after that the configuration is called plug-in stops working for you and It happens for some critical 2.60 Which can be resolved, but there are other compatibility concerns which are under Configuration Reliable So you mentioned that you and you and Evelina are gonna be meeting up tomorrow Yeah, it's definitely in my agenda because yeah, I tried using configuration Like a little bit in the top Okay, well, you just let me know if there's anything you need ahead of that discussion and then just let me know what happens Yeah, I should I should mention that I just recently did a change to Pipeline step which involved compatibility changing the Groovy form by which the step may be invoked without touching the Stapler Binding which is what you'd see in UI or something like that That's possible because the pipeline API is defined an abstraction layer which you can override for the binding as far as I know I'm not clear whether there is a comparable feature in configuration I know there's some sort of custom Mechanism of its practical he is No, I was talking about the process of compatibility changing how you define the The Ml form for some particular setting There's some way that you can that a developer can write a manual override that can compatibly switch Ml to the new Well, like if there's anything you need for me next week But around that meeting just let me know I will not be traveling at that point To be great. Okay. Thank you. I don't know what exactly I may need but So I think that's that's all I really wanted to go through is this quality bar and and bring up the configuration as code topic Role, do you have other things we needed discussed today? No And all I can Jesse I assume the same. Yes, no, maybe some Yeah, nothing from me. All right. Well, thanks y'all for for joining Roe Baptiste and I will probably be chatting with you tomorrow morning about some of the quality stuff once he's back from his joyous French public holiday Stay all later. Okay. Bye