 Are we recording? Yeah. Cool. Welcome everyone to the Jenkins configuration as code office hours for March 25th. On the call we have myself, Oleg and family, John, Joseph, Sladen and Antonio. We've got the agenda which is sitting in Gitter. If anyone wants to add anything feel free. You can get to the document from the bottom here. We'll start off with any news. So recently our shaded snake email was extracted out to an API plug-in that was done by Emilio with Antonio's help. So that's merged to master but not yet released. We have, I think we went through this last time, support for additional user attributes. So that's currently with the local security realm. You can, you'll be able to add things like email address, display name, time zone, SSH authorize keys and a few other things. It should be adaptable to other security realms, but I haven't tried yet. So other security realms can probably use ours, but it may need a little bit of work to make it so that other security realms can adapt. It's probably restricted at the moment, but there's been interest in, I think there was someone in Gitter who was using the Azure AD plug-in and they wanted to have the authorize keys managed by JCASC. So we'll probably wouldn't be too hard, but the groundwork's there for that now. So probably might come back to the milestones one at the end if we've got time to go through it. So system read was merged a few weeks ago. So JCASC has support for it's merged but not released waiting for the milestones before doing the next release at the moment, but we may need to move on. The bomb version bump is still there. It's currently ignoring the failures in CloudBees folder. Both Jesse and Oleg said they'd take a look at it, but I haven't heard anything. It'd be great to get this over the line at some point. I'm not sure if, yeah, so basically I just ignored the test because I couldn't figure out why it was failing and that was enough to get it to be a green build, but I haven't heard any feedback on that. CIG and CIO as JCASC haven't touched on that recently, but the AWS side of it is starting to work on CIG and CIO and there's a talk of moving the Jenkins master to AWS and that would be done with JCASC and the groundwork is there for it. Just need to pick it up again. Yeah, regarding moving to master, we have one major obstacle, basically a lack of infrastructure. AWS code for AWS. So right now everything on AWS is configured manually. It's not just about JCASC, it's about maintain infrastructure. Yeah. So I believe if you will need to rework it entirely at once, if you want to make it master to there. Yeah, yeah, there's no current rush to move it there. Even if it was, I think the current one could be adapted on without moving it as well. I'll try to pack this up the next couple of weeks, hopefully. Secrets encryption with external secret key, Oleg. Yeah. So I just put it to the agenda, firstly to highlight that it's still in my hall of shame because I got a couple of private pinks over the past week about this pull request. So I declared my intention to get it over the line and it deployed my development environment. I hope to get it done for me right now. The main problem is of course, encryptions and certificates, because one doesn't easily implement it right in Java, but I hope to get it over the line. Cool. Well, that'll be good. We have a configurator API plugin here also by me. So I'm not sure how long you plan to delay the release for the current master branch. I want to try to implement configurator API so that we don't have to bump the core dependency for JCASC. But yeah, I wanted to work on it two weeks ago, I didn't get to that. But if I have any time, I will do that. So the current plan is to release once we get milestones in. Yeah. In the worst case, we just released the version of JCASC and then we do a next release where we downgrade to the core dependency. Yeah. Yeah. It's possible it will work so it's not a bloater. Yeah. Yeah. Plug and compatibility highlights. So Adrian merged the mailer plugin pull request, but it hasn't been released. I pinged him yesterday when he said he would do it, but then he was having issues with Windows CI. I wasn't passing. But I think that's most likely because there's been a lot of instability in the infra over the last week. Yeah. I spent some time yesterday to get it re-triggered. I believe that now master branch is still failing. Yeah. I believe it passed once. And in the worst case in this plugin, we can say that we go without windows because there is really no windows dependent functionality in the plugin. So we can leave use of it for a release or two. Yeah. Yeah. Time zone property. I think that's sitting, waiting for Oleg as he put it on hold. It's got a few approvals, but I think... Right. Okay. I'll load on my best review today. Cool. It should be straightforward. Hopefully it's a very small change. But it does impact the data, possibly. Admin monitors, this one's... Everyone seems to love reviewing this PR. It's getting people from all over the place jumping in on it. But I think it's, I think it's really, but everyone, so something that's touched so little, everyone is very interested in the thread safety of it. It's had about 10 different review cycles and for like a 15-line change, but pending a couple of people approving it, I think it's ready. Okay. Log recorders, that one's basically admin monitors, but a lot more complicated as it's part of the public API. For this, maybe we need to consider changing the complementation. So basically the situation is similar to plug-in manager, because JCASK works quite late in the initialization cycle, so we miss log entries, which we created before if we can configure log recorders with JCASK. So as we wanted to move a plug-in manager earlier to the startup cycle, this plug-in installation manager library or whatever the other approach for log recorders, we might need to do the same later. And maybe, for example, for system properties or whatever. So if you want to have integrated CASK experience, then we will likely need a core library for that, not the implementation in the JCASK plug-in. Yeah, possibly. It will certainly give the full experience, but it depends on what people use log recorders for mostly. For me, I've mostly seen it for plug-ins during runtime. Anyway, it's better than nothing. So this public request should be merged, but yeah, there is a probability that we will have to rework it a bit later. Yeah. Yeah. The complication with this is that it's part of a poorly designed public API, and maintaining compatibility is difficult. Well, you have an opportunity to change some APIs. Well, we can duplicate a lot of methods there because I doubt that anybody really uses them. No, it's three plug-ins that touch it. Oops. Okay. So do my best to review all the core requests. I've been so behind Jenkins Core and other stories, but I'll do my best for CASK things. For the rest, I think I will be still behind because of the JSOC student application period and then project selection. Yeah. So we've got some roadmap entries for the JCASK subproject on the agenda. Yeah. So system readers delivered, well, system read capabilities delivered, and JCASK has it as well. Yeah. So for me, system read is still in progress with the first roadmap because we have a follow-up epic with a bunch of changes. So even if we have support in principle for roadmap, I would rather prefer to... Yeah, in progress. ...prelease when we have a good end user experience for that. Yeah, absolutely. Yeah. Pretty much at the same for plugin compatibility, though it's harder to define when it's done, but I think that we should add it to roadmap because it's a pretty important topic for the Jenkins community. That's a difficult one because you can't really see it, and then, well, you could have 90% of plugins compatible, all plugins with over 50,000 installations compatible Yeah, I agree. But yeah, we can mark it as a progress and then think when we set it to completed. Because right now we still have Jenkins Core, we have some plugins which are not compatible with JCASK, I mean the popular ones. So I would rather say that right now it's not completed, but yeah, we put it in progress and then do something about it. There's not many major ones. This doesn't change very much anymore. Yeah, because partially it's in GitHub, partially it's somewhere. So I think that while working on the roadmap, I will likely add an entry to the JCASK sub-project page. Just reference GitHub issues, because we have a review issue there and Jira and so be it. Yeah, yeah, and how to help and documentation, that sort of thing. Suggestions, welcome. There's probably a configuration source API. I've taken a bit of a look at it and made some progress on it, but got distracted. I agree it would be a good addition to the roadmap. Well, we can put it as future or maybe a short term. I'm not sure what's your plan about that. Add configuration source. It doesn't look that difficult. It's just fiddling with the classes. Well, but it would also include some implementations, right? So for example, there's three implementations we were discussing this slide in before. Maybe other implementations because API is good, but we need again a story which is consumable by end users. Yeah. Yeah. Yeah. Well, so yeah, this is delivering the API and then there's the implementations. So the plugin would come with the simple ones out of the box and then the clouds would be off in their own plugins. But yeah. I'm not sure what else there is. So the secret side of it that you're working on. It's reasonable, but I don't think that it's important enough as is. Now there is another JEP, JEP 225, currently pending review, which would create a globe. It's not. It's not. Yeah. Oh, is it not merged? It's in a separate repository JEP. Okay. You can open pull request. So folder there for any credentials provider. Yeah. I believe that in its motivation or JCASC is referenced. Yeah. I need to talk to Chris to understand what are his plans about that because it's not ready as a draft. Right now. Yeah. I think that if there is consensus that we want to proceed with that, then it could be a roadmap entry. Yeah. So potential for things like, yeah, making it easier to define folders, making it easier to define jobs. Some of the more difficult sides of. You mean defining the jobs of folders as YAML? Yeah. It would be nice, of course. Job DSL works, but it's not very declarative. Yep. So if anybody has ideas like that, just put them in the developer mailing list or submit against my pull request so that we can integrate them. We will still have some time to finalize the roadmap before it goes public. I mean, one to months at least. So we can discuss it later, but starting these discussions earlier would definitely help. It's, I mean, it's a living document anyway, I assume, so you can just be updated whenever we want. Exactly. Okay. So that'll be the main list post. So the other item that I skipped over was the milestones pull request. So I think we've got three issues with it at the moment. One that the test fails quite often on Java 11. It fails. It's failed once on Java 8. Two that Oleg had the concern about race conditions between JKS and Groovy Hooks. And the other one was that there's been reported issues with Job DSL and Job DSL running before the Githier servers are loaded. Yeah, so Job DSL is something complicated. But I don't think it's really related to this change because if you have race conditions now, you should have had it before. The issue with the Githier plugin is that it has some validation that it does based on the server when it tries to create the job. And that it should only do that on one time when it like tries to check out stuff. So before Jkask is fully loaded. Yes. But again, it should have been happening. Or maybe not. No, you're right. Before it was a race condition. So depending on your luck, you would have to go to different results. Now it would be fairly consistent. Which is probably an improvement. But you need to do something about it. Is that just a change in the Githier plugin required? I would say it would be a change in the Githier plugin. Well, it shouldn't do validation on the thing that a job wants to have for it. But I've seen other plugins that did that. And those we fixed that assume something when you change the job with that validation. Yeah, the problem that we still don't really have documentation of how milestones should be used. Maybe we really need to start a JEP or whatever for that. JEP not as a full-fledged process, but as a documentation page. So for example, right now we cannot point to Githier plugin maintainers to anything. But it's not really a milestone issue, as I would say, for Githier plugins like that. They shouldn't apply any assumptions to global configuration when JEP results applies to or tries to apply a job. They should just apply. And then when usually all the other plugins, when you run it, it does it on JEP or runtime when you try to execute the job. It does the logic that it needs to check out. This server connection works and stuff like that. Yeah, we have a lot of such form validation logic in Jenkins, but we don't invoke form validation in JCASC. So if we assume that we started in a common Jenkins form validation, we would have had a lot of similar issues. Yeah, Githier plugin just does it another routine. Okay, so maybe just going back to the groovy issues. So for groovy issue, I believe that we need a fix in Jenkins core. So the one which I asked to remove from the original request from Francisco. So we get it, we document it, because right now groovy hooks behavior is just not documented. So we can fix it as we prefer documented the current state. And then if you introduce new milestones for those who want a different behavior, new milestones and new groovy hooks. But yeah, for me, the only feasible way is to actually do it on the core site, because otherwise you cannot really combine groovy hooks and JCASC anymore. Right, so as you say, leave the current one as is but document and add new hooks so that people can use different ones if they want to. Yes, or maybe just introduce a new groovy hook. So for me, the main problem is the current state that we have LCS baseline, which doesn't have a fix. So if you just reverse it and say it's a fix for groovy hooks, then okay, it can be recorded to the next LCS release. But if you introduce new milestones, document everything, it will be much harder to be recorded. It's still doable, but we need to talk about that. So I think that you can just assign the section item to me because it was me who caused that. And I think that just in the top. So adjust to add new milestones. So not adding a master's add new groovy hooks and Jenkins core. Well, yeah, we need to get new hooks and Jenkins core. And we need to fix the behavior of the unit hook. Maybe because so the problem that unit hook is is it makes no sense. Anyway, so we need to define strict initialization rules there. And I will probably just proceed with what fronted. So we retain status quo like we had before the change. Because right now we need hook can be triggered in parallel with job loading or it can be triggered after everything is initialized. So you cannot really do anything reliably with it. Okay. The other issue with this poor question is the, so there's a test here that tries to reproduce the race condition. This test initializer. It's using in it. So it's using a cloud and using a whole bunch of stuff. Not sure if it needs all this. So she's in cloud and LDAP security realm and a bit of other configuration. And it's trying to it's trying to get the git tool configuration and check that the file has been created. But this is this has not been very stable. Just trying to remember this test was doing. So once it finds the git tool file that creates a file to say that it exists. I was trying to run after jcasc and before job loading. So I'm not sure whether we need to adjust the test or not bring it in or I think that this test mostly tests the code is written. Yeah. So as long as the code is written correctly, basically the test just confirms that. And it will be quite hard to maintain that. I don't have strong opinion and I can leave without this test being just to be moved to comment it out for now. Just to recommend that we need to have something more stable. Yeah. So yeah, I think I'm happy with that as well. I would probably remove the test before merge if we're happy to do that. It's not reproducible locally from what we can tell. Francisco around 20 times locally and wasn't able to reproduce it. It's fairly reliably reproducible and see I possibly slower and other things going on. Okay. So let's just agree for now than that will not merge this but to move this forward. We just need the groovy hooks sorted. Is that fine with everyone? All right. No objections. So that's everything that I have. Has anyone added anything else or anything else they want to go through? Yeah, maybe one question about plugin installation manager project idea. I wasn't following the guitar shirt closely. But my understanding right now that we don't have students applying to it. Right. I think I've seen no students interested in that. Okay. Oh, it doesn't particularly block us because we still can do community bridge if needed. Or we can implement whatever we need on our own. So, yeah, I was just wondering what the current state. There's been users coming in with questions and whatnot, but there's been no one. No one interested in the project that I've seen. Well, you like to have a huge search of applications and questions just in several days. But I would say that success ratio of these applications isn't a bit high. So let's see where it goes. Okay, sounds good. Yeah, actually I was interested in this project idea, but you're allowed to apply for only three. It's difficult to make out so many proposals. Yeah, probably you shouldn't. Yeah, exactly. If you're willing to work on this area, you can definitely do something. Or maybe there should be, could be some opportunities. So, yeah, for example, if you talk about Docker Poland and Docker system proposals, there is definitely a lot of opportunities to interact with Jacob. For a bit of a checks API, yeah, there might be some errors. I'm not sure. Probably not other than just being compatible with it. Yeah. So, but let's see. Yeah. I submitted a single pull request to the plugin installation manager. I guess there needs to be tests added to that PR. So since a project proposal is over, I guess now I have some free time to, since the results will be announced a bit late a month later, I guess. So I guess something I can, I can maybe contribute to some of these areas. Yes. Tests and. Yeah, there's a via mock test here. I don't know why. Probably just infrastructure failing. Yeah, just died. Yeah. More concrete is not a stable engine. Yes. Sometimes we've had issues. As I got in quite a mock, I did a little bit, even more suspicious to failures. Yeah. Yeah. All right. Anything else? I'll try to get milestones. Pull request submitted tomorrow. Because it's already a bit overdue. And since maybe a subject for that too, but working. Yeah, I'll try to do as soon as possible. Okay, well, that would be good. Great to get this out. Right. Thanks. Thanks everyone. Bye. Bye.