 Hello, welcome to the regular Jenkins configuration as core project meeting today's May 6 and we just run the common agenda. We will talk about news, about JCAS releases and like ability fixes and then everything about ongoing development and other project stories. So, we have four participants on the call. It's John, Tim, Adrian and me. And yeah, unless there are more topics to the agenda, I suggest to just go through these ones. Actually, I have one. We will have a UI UX online hackathon. So, I'd like to discuss briefly today. Okay, so let's take a look at news. So, last time we met on April 25, at that point we had one JCAS release, I guess. Let's take a look. I guess the current version is 1.39, right? Yeah. So, yeah, basically, we had no releases since the last meeting, though there are some ongoing changes. Yeah, from what I see, we've finally integrated the bomb folder zero into the plugin. And yeah, thanks a lot, Tim, for keeping the do-of-materials integration in place. I guess we will still need to integrate this version. So, yeah, no new releases. And what about plugin compatibility for the stories? Do we have something for those weeks? I guess not. I don't think anything's been merged that I know of. It was one or two, I think, hours. Yeah, it was a quite a silent week. Some people were busy with Google Summer, of course. Other people were just pulling core release automation. Yeah. So, that is someone going point of answer. So, regarding going development, we had a bunch of stories we discussed at the last meeting. So, I guess all of them are still going on. So, build-of-materials, system-read-permissions, anything else. For system-read-permissions, thanks to Tim, we got more and more changes in the changelog. And I guess we got all major fixes in the 2.235. No, there's one left. It was going back and forth with Daniel on Sunday, trying to get it in. Sorry. Agents is not there yet. Yeah. I think it's in their time to re-review it. But we got almost done. Well, I think that we still got a number of changes in this week. So, why it's important that this week is likely to be the new LCS baseline. But, yeah, we'll just keep working on these and other changes in the next three levels. There is still a lot of things that we could do to enhance system-read-permission. This is actually one of the reasons why I brought up the UI UX Online Hackathon, because it's our opportunity to facilitate some contributions around this story. And, yeah, we would like to discuss it with other G-Cast contributors. Have you all heard this in the announcement? Yes. Yeah. So, long story short, we would like to have an online hack test in late May. So, we tend to start on May 25th. And it's likely to be a five-day event or maybe we'll roll over it over the weekend. So, it would be seven or eight days. The idea is to facilitate contributions around user experience. So, what it means, user interface, user documentation, and also connecting success stories from Jenkins users and share their experiences. So, there is a proposal in the developer mailing list about that. And we will have a meeting tomorrow and advocacy and outreach meeting. And after that, if everything is approved, I will start publishing the website for this event, etc., etc. And, yeah, my interesting question is with stories we could address. And for me, one of the interesting stories for configuration escort is, of course, read-only interface. So, it's not read-only interface for system configurations and also for job configurations. So, one of the changes team did one month ago. He applied the same JEP224 engine to job configurations. And actually, we could continue working on this topic. Maybe there are some new between the tasks or advanced topics so that, yeah, we could basically improve experience of Jenkins admins and common users who don't have right permissions to the instance. And I think it would be beneficial for the story solver role. So, question to you, does it make sense? Do we have an opportunity to find enough new befriended tasks and not so new befriended ones there? I've added two new befriended ones to the epic. They both shouldn't be very much work. But I'm planning on leaving them for other people to pick up. So, it's for system read for admins, right? Yeah. So, another one is extended read for jobs. I didn't test it so much, but my impression is that there are still a lot of controls we would need to modify to improve work condition. Yeah. Pipeline should probably have an issue raised for that. I think the pipeline looks pretty horrible with standard read at the moment. I'm going to try to get the video. Oh, I'm jealous. And yeah, another story which was recently revealed by Daniel Beck and King is extended read for agents. Because, yeah, technically we have support of that inside of the Jenkins core. But yeah, as far as I know, nobody has ever used that. We have extended read plugin. It also doesn't enable this permission. So, yeah. Yeah. It was added seven years ago for like one or two API endpoints and no UI. Yeah. So, most likely it doesn't work. Most likely it's Pandora box. But if somebody is willing to test that and maybe get it fixed, it would be also nice. So, the reason is not permanent agents. It's quite rare that people have access to configuration without being able to do it. But for cloud agents, it would totally make sense. So, if we could edit that, well, technically it uses just two to four agent engine as well. And in the most cases, people who use extended read for agents would also have system read. And maybe we should even adjust inheritance before publicly open. The PR for that is open and very close to merging. Okay. Trin had many iterations of me and Daniel. Okay. So, basically it would be box crop. Yeah. Stank. Fixing stuff. Okay. But there's still to be a good improvement. So, anything else we could consider for Hackathon except system read permissions. Maybe it's actually enough. Okay. So, if you have any other ideas in mind, please comment in the developer mailing list or there will be more documents. But yeah, I will be working on initial lending and I will add a job two to four. Well, basically these stories there might be as a separate ones. Hope it will help us to facilitate changes there. So, the next story is bill of materials. Just checked this morning. We still have a pull request with Jenkins configuration as code plugin update. This one. And my understanding that we are still blocked by J-Cask test harness dependencies and other fun stuff is directing. Yeah. Yeah. We briefly discussed the last meeting. I was thinking about doing. So, we will need to fix a plugin compatibility tester. So, it's a development utility which verifies plugin compatibility. And I guess the main problem for us is to have a configuration as code test harness manageable with this PCT. And in order to do so, we will likely need to include it in plugin form. So, this part is doable and I'm happy to help with it. But there is also a separate part. We will need to update all plugins which explicitly include J-Cask test harness. We will need to upgrade them to the new plugin form version. And it means that we will need to upgrade them for the zero. So, I just wanted to have a sanity check whether it's possible, whether we're ready to invest time in that. I don't quite understand how that would fix this sort of thing happening again. So, the plugin POM, they would have an explicit version, say 1.40. But then we do another change like this in 1.42. Won't they still be using 1.40 from the plugin POM? Wow. So, assuming that J-Cask test harness is stable enough, so that the library can test multiple versions of J-Cask plugin, it should be, it should work well. It's basically the same we hit with Jenkins test harness eight years ago or so. Because originally it was also highly tied to Jenkins core versions. But now you can use Jenkins test harness with multiple core versions and the range is actually pretty wide. Yeah, I think this is just quite a special case really. It could also be fixed by just changing script by, if we released a back ported version with the snake YAML change and then bumping script security to use that version. It just needs to be, it just needs a version of J-Cask that's compatible with snake YAML API plugin. So, we'd have to release a version that has a minimum version of 2.164, I think it is, that has the snake YAML PR plus the bug fix on top. That's probably quite a low effort fix. Yeah, that one should be doable. So, basically you think that PCT is not needed to get this landed? No, it's only script security that's currently affected as far as I know. I don't quite, yeah, I mean, there's many different ways, there's multiple different ways to fix it. But maybe a good way to do it is to split the two things as a part because there's no, I know we're using it for test sources ourselves, but what we could probably do is split it out so that the test harness is separated out as a separate release. So, they don't follow inversions. We don't really change the source that much. Well, there is even more aggressive change we could do, we could include a JCASC test harness right inside the Jenkins test harness because why not? We already had some cases of that when we were working on the role strategy performance. So, basically a Jenkins test harness includes some accessibility engine which can be extended by a JCASC plugin for doing benchmarking of plugins. And theoretically, we already depend on some plugins here. Go correctly. Yeah, something like matrix authorization, well, it's test scope. Yeah, also, JCASC is also in the test scope, but in principle, nothing blocks us from putting the code directly there. I would be up for that because it's a small package that's a few files, right? Yeah, we might need a separate test package for us created because I think we have a number of tests inside of the test harness module, because we're testing stuff that requires the test harness functionality, but we don't want circular dependencies inside of our code because test harness depends on JCASC. So, we might need our own test module which depends on test harness. Okay, if you do a test module, it's better to do it as a separate repository because in such case, you would also have separate release cycle and we will still have dependable or whatever picking it up. Yeah, so yeah, we could convert Jenkins test harness to multi-model repository, but I don't think it would improve situation a lot. So, if we really cannot avoid circle dependencies, then yeah, separate module. I still think we could separate it out, yeah. And then have the test still use the test harness that we have because it's just there for calculating the... So, I think separating out would help, at least. It should be doable, but I still... I think we still need to do something to get over this breaking change. So, yeah, as model things. So, and the other option is fixing PCT to update properties rather than rather than just overwriting a specific dependency value. Yeah, so we're here to fix PCT. I'm up to do that, though any change in PCT comes with some risk because there are multiple modes of PCTs running. There is already a lot of dark magic in the implementation. Yes, I've gone through the guide. Well, we improved the code a lot over the past two years when we started productizing that, but still. So, for example, there is a hook engine and all multimodal repositories need hooks to properly discover components. And we could use this hook engine to rewrite versions, but yeah. Well, we already have configuration as a code hook, by the way. It's just a parent locator, though. Yeah, well, we can add more logic like overwriting the library there because, for example, we can say that in this in PCT, if you test against the G-Cask version, your G-Cask test harness should be always the same version as G-Cask plugin. Well, for the moment, it makes sense unless we split it out. And yeah, it can be implemented in code, though. I would really like to have a plugin pump for that, but even without plugin pump, it's doable. Yeah, there's many options, many things. Yeah, I can make a try and implement the plugin compact tester change. Maybe a question toward what would be the downstream impact if we do that? Because at CloudBase, we use a plugin compatibility tester a lot. And I wonder whether such change in plugin hooks would cause any problems. I can have a look. Okay, so yeah, I wanted to code something. Yeah, so I'll just add an action item for me to create a test patch. Yeah, I'm still not sure whether we will need more changes to get it running, but yeah, I will try. Okay, anything else about bone? So we have a number of other stories, like CAC, G-Cask, Syncret encryption, the Greater API. I guess there is no updates on these stories, so we can skip them today. Any other ongoing development we should mention? Or any other political errors or whatever, where health is needed? I don't know. Nothing, J-Cask related, really. Okay. Yeah, the CIG can say I was stuck with giving AWS account setup properly, rather than using the CloudBase one that's all manually managed and no one else can have access to it at the moment. Yeah, I didn't have access either for the record. Yeah, I have an action item to get it fixed, but it might take a while. Okay, maybe I will check. So yeah, I think that's it. I wanted to discuss switching to a new Zoom account. So just to clarify, right now we use an experimental CDF Zoom account, but we got a separate one for the Jenkins project. And I'm currently working on process updates, so we can give project leaders, seed leaders, access to the Zoom account. And in this case, we want to meet Mark Wait, Marki or somebody else to record the meetings on an official account. My question is, is everybody fine with switching, starting from the next meeting? Yes. So Tim, I will share permissions with you. Still, it's a kind of shared account, but I think we can do it. Let's see it. Do we have any other topics to discuss today? Okay, so here may be a quick update from me. So we have got a number of pool summary of code projects announced just on Monday. And there are some projects which are actually related to Jenkins configuration as code. For example, as Leydin, he was our community bridge mentee working on JCAST peer tools. At least somewhat, he will be working on a custom Jenkins distribution build service. So a service which allows to define the configuration, including JCAST, and build the ready to fly images for Docker, for Word files. So basically like custom Word packages works, but as a service, I believe there will be some changes to like to JCAST there. And also, there are other projects like fingerprints, in GitHub checks, API, machine learning, which we like to include some level of JCAST related changes there, maybe more. So there will be some, you like to get some contributions. And maybe even more optimistic topic is about Jenkins window services YAML, because once we switch it to YAML, we will be able to use the same Jenkins YAML to configure. It is a service if you run on Windows. And if you want to do the same on other platforms like Kubernetes, you could also see how you could integrate JCAST and Unified YAML. It's a moonshot, but technically it's possible. So yeah, hopefully we'll get something new out of this Google Summer of Code. I guess that's it from me. And yeah, thanks to everybody. Are there any other topics before we close the meeting? Okay, I guess not. So yeah, thanks a lot to everyone. Thank you.