 Okay, so welcome to the Jenkins configuration as code office hours for March 11th. On the call we have myself, John, Adrian and Antonio. We have a few things. So the agenda's in the GitHub channel. Feel free to add anything to it. I've prepared a bit with some of the recent pull requests that have emerged and recent ones that are open. So we have a few items that emerged on master and pending release. Just quickly go through them. So we've got a, we've bumped the minimum Jenkins core baseline to 222 for the milestones pull request that Francisco is working on. And also to allow us to use the system read feature as a side effect where Jenkins core became compatible with the proxy. Proxy configuration quite a while ago. But properties aren't quite the same as they are in JCASC. But the Jenkins core configuration gets picked up first. So there's a breaking change where the password field has been renamed to the secret password. We'll update the release notes before releasing. I don't think it will affect many people, but just to be aware. We have added support for configuring additional user attributes for the local security realm currently. It should be adaptable to other security realms. But some examples. I'll just show a brief example of it in the demo folder. So you can now configure name, description, display URL provider, which is where you want classical blue ocean and your slack user ID. And there's a merged pull request for the SSH public key, but it still needs to get merged into Jenkins core and released time zone and mailer, which all have pull request open. But so I think this will be useful for some people. And I think it'll be more useful once some cut some of the other security realms can adapt it for things like slack user IDs and public keys. There's been a few people asking for it. And fixed a bug on symbol resolution. Previously, we always took the first symbol in the list. So symbols are a friendly name for a descriptor. And if you're class, so we try and detect a nice symbol based on the class name and some conventions. If this allows you to say, don't detect it, this is what you should use instead. It also allows you to supply multiple possible ones, which is a way of backwards compatibility. So you can change it. You can rename it without breaking old classes. But we always took the first one regardless, which meant that when the pipeline model definition plugin was updated recently, they added a new one, which broke any existing users, which had a bit of effect on a few people. So now we allow any of the possible symbols when you import. And we always export the first one. And just been going through trying to get some of the stuck dependable PRs merged. Quite a few enforced problems that I've just been fixing up. So that's it for the recent news. So we still have the milestones progress open that Francisco is working on this one here. There's a couple of outstanding points left on that. One. So one is that the unit test doesn't pass reliably on Java 11. I've also seen it fail once on Java 8. So it's a unit test that's trying to reproduce the race condition. And we need to decide what to do about it. But and the other issue is Oleg is worried about groovy hooks and how this interacts with them. Our last office hours, he said that he was going to take that up and take a look at it and figure out the way forward. I don't think he's had time though. So I think we just need to possibly get together with Adrian and Oleg and discuss what we're going to do to finish this up. It would be good to finally get this over the line. It's been open for a month and a half now, almost a month and a half. Has anyone got any thoughts on this? Not really only about the groovy hooks. I think those hooks are applied here in Jenkins. I mean, even before Jenkins has started. So I mean, it shouldn't be any race condition. So they use the old unit milestone before the new unit milestones were introduced. So before JKS was using the same as groovy hooks. And now groovy hooks stayed on the same one as before and JKS was using a different one. So I'm not fully sure. I'm not fully sure the issue, but it's here. This is the specific line. So users job configured, users job loaded. Okay. Yeah. Yeah. I'm not sure what to do about the test whether the test is finding an issue or whether we need to disable it. It's not reliable. It's not something we can have on CI, I don't think. Whether there's a way to fix it. So system read permission follow ups. We've added support to JKS for it. So you can view the configuration as a system read user. There's quite a few core PRs outstanding. Mostly waiting for the security team to have time to review them. Still stuck on the bomb version bump. CloudBees folder is failing. So CloudBees folder is failing for one of its dependencies, one of the workflow one trying to load the structs plugin of the version that was detached. I managed to get a green build by ignoring the test failure. I'm not sure if that will be acceptable or not. But we've had this open for a long time. So I think Jesse said he's going to take a look and only said last meeting you take a look as well. I spent quite a while looking at it and couldn't find why the wrong version of structure has been picked up. Let's do a PCT in mega war mode and yeah, not really sure how to fix it and I spent quite a lot of time on it. The other is the other bomb issue, which has has a similar issue and has been similarly ignored just so we can try and move it on. JKS demo, we don't know what this is. I think Orleave might have updated his demo or not. I'm not sure. That's from the last meeting. I'll just remove it. I haven't touched the cio.jkenon.io as JKS. For now it was, we're kind of waiting to see what happened with AWS. We've got AWS credits have now arrived, something like 10k a month. It looks like for the moment the cio.jkenon.io is still on Azure but spinning up as many agents as possible on AWS. So I might look at moving that forward and just pulling in the AWS configuration. Plug and compatibility highlights. So file credentials is fixed for the credential. So they file this is a certificate file and regular file I think with the issues. So that's been an issue that's plagued people for a long time. If they had one of those credentials on their Jenkins master then export or fail. So that now works fine. As of credentials two, three, three, and the previous, there was one previous version of JKS that was released. 1.36. No point in when exporting file credentials. And something to do with exporting a user. I think it was trying to re, it was trying to re-import a user without a password or storing a null pointer. That's been fixed as well. And some documentation fixes. And the other one is we've got a progress token on the mailer plugin for allowing and configuring the user's email address. I added incrementals to the PR which Adrian wasn't happy with. But there's now a separate incrementals PR. Yeah, it's fine. I'll manage that later today. Cool. Thank you. Nice. And then there's also one on core for making the time zone. Property compatible JCASC. Waiting for someone to review it. This one was a bit weird that this is the only user property I could find that was explicitly calling save and user.save. And user properties have this transient user associated to them which stores a weak reference to the user. That is, that the property is associated to. There's no way for JCASC to set that. I tried. Well, I tried to set it. I couldn't find a way to set it, basically. But it doesn't seem needed at all. It works completely fine without saving it. And no other properties use this pattern. And the class is fully restricted. So it seems fine to me. And there's no usage of it. There's no usage outside of core. I couldn't see any reason not to just remove this as both the UI and JCASC worked without it. If someone wants to review this change, it would be appreciated. And just to note that there's a GSOC project that has a slide associated with JCASC in that they wish to add support for at least putting the plugins into the same file as JCASC, even if it's not JCASC self-loading it. But yeah, that's it from me. Has anyone got anything else they want to discuss or anything here they want to go back to in more detail? Yeah, I wanted to check something. So I'd like to start working on a couple of things. I want to check here first just to make sure we don't overlap or step in other stores or something. One thing is the extraction of a Snake Jamel as an API plugin. I think we talk about that in the past. I don't know if someone has started to work on that or not. And no, so we plan to do it, but haven't had time to do it. Okay. So I'll start working on that. And I think that's going to be also beneficial for other plugins that are starting to use Jamel more and more. And so we should stop shading the Snake Jamel there. So okay. And the other one is about the configuration that's called management link under manage Jenkins. I'd like to add some minimum extensibility to that page. Would that be okay for everyone? I think that makes sense. I was thinking about adding that in the users PR because I wanted to have that configurator add like a checkbox to the page because for that PR it means that users are getting exported with lots of properties. And I wasn't sure if say an instance with 200 users would want them to be exported. I've added a system property escape hatch, but I would have liked just to have a checkbox on the page. Okay. So it would have been useful there. Okay. So initially I thought about adding some extensibility to the existing actions like you can do some additional action when exporting a bundle or extending the view for the export view or something. But yeah, I think it makes sense to also extend, I mean, to add the ability to add new things to the page, not only extending the ones that are already there. So okay, I'll have that in mind when writing that. Yep. That makes sense to me. Good. Okay. I create GD issues and all that to start working there. If it's just Jcast related, I'll just use GitHub issues as much more visible. Okay. Cool. Anyone else? No, everything's fine. All right. Cool. Thanks everyone. All in that there. Okay.