 All right. Welcome to the office hours for Jenkins configuration as code plugin. It's 20th of November. On the call we have myself, Tim Jacob. We have Oleg and John. So I'm kind of looking at the minutes for the meeting. We have just a standard agenda at the moment. Welcome, Alfred. So feel free to add anything else to the agenda. Otherwise, we'll just go through it. So the first thing up is news. So anything new that's been Alfred is not Alfred. Alfred is Joseph. Yeah, one of the things I wish was said in case, uh, uh, jcask DevTools project. So we had a demo last week. We are starting presented. There are some wrap up being done. For example, blog post. And after that, we will have online meetup maybe in mid-December. But anyway, we've got quite good progress there. Cool. So since the last time we went through that, I think the last project meeting was three, three weeks ago for the regular project meeting. Something like that. So since then one dot through three was released. So we have a secret source implementation for properties files that's so that you can just have one file with all your secrets in rather than having to have the file name is the key and the contents of the file is the value. So that can be quite useful for people who are still running on VMs or who aren't running in Docker or Kubernetes. Quite useful. A couple of the, the jcask DevTools project enhancement for JSON schema documentation. Misspelling on the API, which had no consumers. So it was corrected. And a few demos and documentation updates and quite a few dependency updates, but they're all in our integration tests. So it shouldn't affect anyone and some more cleanup. So the main feature is the secret source implementation. And pending, we don't, we've only got dependency updates pending currently. In terms of ongoing development. I've had a request for the configuration as code class to be unrestricted. So that the cloud bees beekeeper can decorate the output in some way. Yeah. Yeah. Just another in-flight development, I think. There's a schema generation to finish off the jcask DevTools work inside of jcask. There's currently a couple of issues with that. So one test is failing and there's a duplicate Jenkins configurator because of the Jenkins object and the Jenkins configurator is causing some issue. But that poor request is critical for the schema generation to work properly. I thought the test framework was finished, but you should probably have a look and see where that's at. And the other one was the null pointer that Oleg started working on, but wasn't able to finish, I think. Yeah. I dropped the poll on that because yeah, I just had six weeks of travel. My plan is to return to configuration as code and also to yeah, docker packages, which are quite related at the moment. Cool. In terms of other in-flight development, system read seems quite stalled. So the feature toggle approach was implemented and it's been waiting for feedback. For a month or so. So what are we missing in creating this blue request now? It implements the feature toggle based approach. The only other, yeah, whether it's possible to make it read only, but also agree that it's very difficult without touching, without a lot of hacky JavaScript or patches across a lot of plugins. Yeah. So we have much conflict there, but yeah, I assume there is a consensus about feature flock and I assume so. We could probably lend it one of the next week, yes. Yeah, the low light a bit. We should have new baseline selection today. So it means that it misses Jenkins LCS, but on the other hand, I do not see what would be the schedule because usually we used to skip one month due to Christmas break and other things. So maybe it applies this year as well. I already think Oliver Gonza. So I'll try to understand what the status. Sure, sounds good. Yeah, I resolved the conflicts after this anyway. Okay, thank you. I don't think the integration tests are still in progress. I believe that the most of them have been merged? Most of them are merged, but I think there was a few that weren't working, but Victor did a lot of work on it and probably not this one gave up. So Samuel, he never got working in TFS. I don't know if he would want to merge the TFS one. You have to, there's a library that's not published to Maven Central, you have to download it. And it's not very nice. Yeah, so it's just Samuel and TFS. Let me close this. The other thing was the proxy to Jenkins Core. Poor progress was merged for the proxy configuration class. So that poor request was just for proving the integration. VS Code plugin for JCAST. So at the last, the kind of sub-project meeting last Wednesday, Slayden demoed it and he's going to do another demo in December with like Olex earlier. And there's a couple more features that need to be removed just so that it works properly. Plug and compatibility highlights. Login theme plugin. Yeah, basically just a good one pending release over the line yesterday. But yeah, if somebody has any other highlights, please add them, because yeah, it wasn't tracking plugin releases over past weeks as well. So I need to catch up on this one. The audit trail plugin is almost done, I think. Yeah, I think PA has it working, but there's a couple of questions on how the breaking change. We also have a number of other pending JCAST compatibility fixes. What do you really need to clarify at this date? Anyway, all major plugins are already compatible. So here we are playing fixes here and there. But yeah, I just moved one instance to JCAST last week and basically I didn't experience any compatibility issues while moving a real instance, which is quite unexpected. But yeah, it was nice. Just going to see if SonarCube ever released. Oh yeah, that's difficult part. So I guess SonarGuys just celebrate acquisition now, so probably it's not a good time to ping them. Is there another poor request? I'm just trying to say there's another poor request. Right. Okay, so the main poor request was merged and then the follow-up poor request to make another field optional, which was missed in the first PR. So I'm guessing they're not releasing because they're waiting to merge that. That's been a very slow and painful one. Cool. Has anyone got anything else? Oh, one thing which is probably related. Over the past weeks, I was working on Jinx FellRunner. So now Jinx configuration is called as a part of vanilla package. So basically anybody who's using Jinx FellRunner gets jcast out of the box and you use out the Jinx file, dash runner. And currently I'm finishing the plugin management. So I will be using plugin installation manager created by Natasha Stoppa during JSOC this summer. And basically my plan is to use it right away in Jinx FellRunner. And then I will like to coordinate upstream and this tool in the Jinx and standard for Docker images. Then Jinx FellRunner I plan to support on the other new tool. Cool. That sounds good. I think it's getting a bit more tension now that it's had the one point I released. So some people are trying to use it and... Yeah, I don't expect one auditor release anytime soon because basically I'm just addressing feedback, changing architecture. It also requires some Jinx core patches to be more efficient. So I think it will be, it will stay in beta for a while, but this beta already works pretty well. Cool. All right. Anything else? There's one thing that came up on the mailing list. Some milestones. Yeah, I'm sure it's worth. Yeah, it was about bringing that up, but yeah. Yeah, so basically it's also a change which we will need to do because whatever we do initialization in Jinx core becomes quite complicated. And right now you can reliably use manager jobs of folders from jcask. And yeah, it will change that we definitely need this fixing. Is there a lot of work? Well, it's Jinx enhancement proposal. So I was about doing that, but taking the current state I would rather prefer Jinx board collections to finish first so that we have a clear way how to actually review jobs. Right. Yeah, so yeah, it would have been great to get it in the next LTS baseline, but it doesn't look to be possible. So then it means that the next target for us would be February or early March. Yeah, and then we'd have to bump our baseline to the new LTS when it's available. Yes. So with bringing up all these configurator API discussions, there is no easy way to do it without bumping the core dependency. Yeah, it should be fine. It's not really, it's not really users is the issue. I think it's other plugins using our API. Yeah, just in terms of additions. So where is this? It's too long. I can't see 2.190. So most people are on, 84% are on 2.190. Yeah, yeah, it's non-statistics. So of course we cannot break it. Well, not break it, but they require a new core version. It might cause some issues. For example, if we ever want to deliver another security fix or for plugin maintenance, because it means that whomever wants to pick up new GCAS question, for example, if you offer new APIs, then they would have to bump the core dependency as well. It was one of the main reasons for me to propose configurator API plugin almost three years ago, I guess. But yeah, it's still an open question. And I think that you might need to discuss it again. Yeah, yeah. Yeah, it's not just a matter of moving things. It's restructuring or factoring the cleanly split. Because at the moment, you have to move too many classes. It's not about moving. Well, basically we have leaky abstractions in some cases. So we cannot easily speed with things to do. It will require some work. Yeah, yeah. I've ever had a look at it and it's possible, but it will take some work. Cool. Anyone else got anything? John Joseph. So yeah, one topic. Next meetings. So I created a doodle for that. So if anybody is watching recording, they'll please tell me to the meeting notes. Once I find it again. So we definitely need some votes so we can schedule new meetings. Yeah, maybe since we have some time, it makes sense to quickly discuss it. Basically we have two options. One to keep the meetings in the current time zone more or less. So it means that people from Europe and Asia can participate easily, but at the same time, it's not that comfortable for the United States, especially for East Coast. West Coast, yeah, it's quite late, but they probably can't attend on the evening. But for East Coast, the current slot is not good. So that's why whoever is interested in this vote so that we can see whether this option is fine or whether we need to look for other options. Tim, Joseph, what's your availability in general on evenings? Just in case? Rather no. So yeah, one of the options would be to just have two meetings. So one approximately as is. And another one some time later. It really depends on the participants. Because yeah, probably we will get some usual suspects there like Alexerl and other folks who use Jcast. I'm not sure whether he just finds the meeting. Let's see. Yeah, let's see how it goes. We could possibly alternate time zones as well. Yeah, so just one meeting per two weeks as is. One meeting for two weeks or months in the US time zone. Yeah, let's see. Anything else for today? Okay, so I'll check with Oliver what is our LTS schedule? Cool, sounds good. Yeah, I'll follow up on the guitar shot. All right, sounds good. Okay, thanks everyone. Thank you. See you, I think it's all right. Yeah, at least some of you. Yeah.