 Okay, and we are being recorded. How today's regular Jenkins configuration is good meeting, today is February 26th. So we are sometimes passed after FOSDEM and after other things, and we are getting back to our regular schedule. Today we have only three people on the call, me, Tim, Jacob, and Antonia. And yeah, I'll share my screen to show the agenda. Yeah, I think we just run a common agenda today. We start from news, and then we will discuss ongoing development, and if there are other topics we will discuss then after that. So let's just continue. Regarding news, the main news, we have these weeks that system read permission, it's a long project, my team has been fined. Sorry? Oh, yeah. So this change has been finally landed in the Jenkins Weekly, and you can see that there is not only this change, there are other changes for overall managed permissions. There was a lot of collaboration to get these pull requests aligned, and it's great to see that both of them are landed. You may see that both of them are in experimental state, so there might be some changes in APIs and in the behaviors, but the core functionality there. And now there is a lot of work to actually get it integrated into Jenkins ecosystem, including plug-in patches, et cetera. At least that is our next steps of that. Tim, or would you like to add something about the read permission? No, other than that there's a extended read permission plug-in 3.1 that you can install to activate it without having to mess around with system properties. So just installing the latest version of the plug-in will activate it for you. And there's pull requests in flight for quite a lot of the additional functionality. Needed for this, but the core functionality is integrated. All right, and another advantage of this plug-in is that it provides API, which can be used if you want to adopt system read permission checks, but do not want it to bump Jenkins core dependency. So there is a convenience API, which allows to do some bits. I guess we're going to use it in Jcast plug-in and other related plug-ins. I don't think we'll need it in Jcast plug-in because we're currently bumping it for the milestones. Okay. Yeah, but role strategy plug-in has its add-ins. Yeah, speaking of bumps, there is an ongoing discussion about LCS baseline selection because 2.222 is just probably the last release we can see for LCS baseline. The final decision should be made tonight. And there is ongoing discussion in the developer mailing list about which baseline will be selected. And I guess the current state that it would be this release with all these changes we'd like to get or the previous release, which is stable, but which doesn't include this API changes. So right now there is a thread, there's a bunch of comments. And if you have an opinion, please comment. If you have tested a version or if you would be interested to get these features, also please comment so that it can influence the decision. Because we've been running it in production since for a couple of days. Yeah, I installed this version on Monday on my setup. It works well and the system read permission also works well. And right now I hope that you know to update my demo so that we can evaluate it on the demo site as well. Okay, anything else about system read permissions? I guess the only thing is what it is and what it means to J.K. So the main goal for the system read permission is so that you can have a Jenkins that's completely managed as code, but you can still discover the configuration that's in terms of J.K. And also to allow users to contribute to it easier. So your users can still see what plugins you have installed and what your J.K. Export will be, but they can't direct you to the J.K. Export will be, but they can't direct you to the J.K. So the J.K. Export will be, but they can't directly change it. They have to change it in the code. So the J.K. Export of that will come in very soon of a progress for that in the next couple of days. That's a short introduction to it. Yeah, maybe it makes sense to have a demo at the next meeting because we still need to integrate a bunch of pull requests in weekly, et cetera to provide full user experience for permissioned users. So right now it doesn't do much without... It has the managed page, which is the major part of it. But plenty of other pages that are missing. So yeah, there is a number of pull requests here submitted by team just particular components. And I guess we will be using the same approach for managed permissions because managed permissions also just with the foundation pull request landed. So yeah, there will be a lot of these pull requests. Let's make sure that all of them get integrated quickly so that by the next LCS baseline we can say that this feature is in J. Yeah. So yeah, we could just do a demo maybe today or maybe at the next meeting depending on what you prefer. Yeah, I could probably do a demo today. Just merge them all into one branch. Yeah. Yeah, I should be able to. Yeah. Let's see. Okay, and regarding the rest. So community rich project. We had a project which was devoted to JCASC YAML validation and to Visual Studio Code plugin which would allow editing JCASC files. We are happy to announce that this project is officially over. So there is a final blog post by Sladin who was our main team working on this project. This blog post summarizes how to use the JCASC plugin for Visual Studio Code and how to get YAML configurations from JCASC. So you can refer to this blog post to just install the plugin for Visual Studio Code which is also available on the marketplace. So you can do it quickly as you probably do for the Visual Studio Code plugins. And it has already got quite a number of installations. Okay. If you want to know more about this project they will be online meetup today. So it's 2pm UTC. Basically it will be a demo by Sladin. So team maybe you could summarize what will be there because you've been at the right run. Yep. So today Sladin will be demoing the project, what the project goal, what was completed. And then he'll go through installing the plugin, exporting the schema from... So installing the plugin, configuring the plugin, exporting the configuration from your running Jenkins and then developing configuration as code. Well, not develop... So writing configuration as code configuration inside VS Code with IntelliSense assistance. Yeah, there are some screenshots. I'm not sure if they're big enough. Okay. Now they're definitely too big. Basically once you configure that you can edit the configuration, you can get some advisors right in the IDE. Yeah, it's great. So looking forward to have this meetup and the presentation. And if you're interested in JCAS validation make sure that you join the meetup or we should record it. Okay, that's all we have regarding Qs. And we have some items for ongoing development. The main one is support milestones. Several weeks ago we integrated the foundation pull requests into the Jenkins core. So it will definitely be in the next LCS baseline. We just need to understand what would be the next with this pull request. So Francisco has created a pull request which adopts the change. Here's a bunch of changes here. So if I understand correctly it needs reviews from potential stakeholders. But that's it. I think it's pretty much ready to go. The reason it hasn't been merged was there was a test laking on Java 11 only. And we couldn't reproduce it locally. We made a couple of changes. We upgraded the Java version running on CI Jenkins.io. After that it started passing every now and then before it was failing all the time. And we also changed the surefire to rerun failing tests four times as passing 100% after that. Francisco ran it 20 times locally and was never able to make it fail locally. Are we sure we want to enable that? That's a wrong property because that's usually hiding flaky tests. That's not a good thing, in my opinion. We should try to avoid that. It's possible. The problem is the complexity. So here you can see that the test applies job dependencies and other things. It tries to reproduce the race condition event. Possibly we can just have that test rerun itself as that seemed to be the only flaky one. It was strange that it only happened on Java 11 but I'm not sure why. Yeah, so we thought we could include some more retries here with some delay. But yeah, we can rerun this test. There should be a way just to have this test rerun, not all of them. Yeah. One of my concerns about this change, probably later than never, is about alignment with groovy hooks. Because my understanding that in the current state after the change it would be competing with groovy hooks. I don't think so. The groovy hooks weren't changed in the milestone's PR to core. Yeah, they weren't changed. Yeah, I'm partially responsible for that. Because groovy hooks may be managing jobs. So my concern was that changing the initialization order might be a problem. Just a second I'll find it. I can just open the full request. So let's take a look at what we integrated in the last change. It may not show up because he would have reverted the change. Yeah, it was basically my advice. Yeah, this one. So yeah, now it happens after job loaded. So it might be a problem. I think that we definitely need to look at what we do before we merge. But I think that you could just apply it as a separate pull request and maybe even back port it to LCS at needed. Yeah. So I didn't think about that when I was commenting. For me groovy hooks would be much more important than job management and groovy hooks. But yeah, I think that the easiest way would be to just fix an advantage score and to apply original implementation by Franziska and maybe introduce a new initialization milestone for groovy hooks so that whoever manages jobs can move them. But yeah, it might be a problem. We could possibly just document it in here. I think a lot of the use of groovy hooks has declined since JKS has got a lot more stable and popular. It still uses for it, but it's a lot less popular than what it used to be. Yeah, it's less popular. The program that many people use these tools in combination, each use each other, including my steps. But yeah, you can just leave it to me because I suggested to reverse the change and now I should follow up. Okay. So system read permission follow-ups. I guess we discussed everything. Yeah, if there's any more ideas, there's an epic on JIRA for it. It's got five or six stories or issues currently. But there will be a lot of other minor things. So for example, I discovered that some buttons still appear when they shouldn't. For example, in descriptor drop downs. So thanks a lot for conversing this task to Epic. We can just dump more tasks here. Yeah, I think you need to log in for them to show up. Yeah, I still don't understand why Epic's configured in that way in JIRA. Or you have to log in on your phone to see anything. Yeah, by the way, somebody put this ticket to negative community ratings. The reason I couldn't explain. Actually, there might be one reason, but I also might create a few extra topics here. Cool, that would be good. Yeah, it will be a long project to get everything fixed because we have UI controls implemented in the Play Games. We also have some UI controls which are currently implemented in JavaScript, which is going to be an additional challenge. It's not too hard to adopt them, but it just makes it harder. Well, it will take a while, but the feature is experimental for a reason. We have some time to get it adopted. And anyway, it provides a better interface than it used to provide before. Because before that, the only way was to just either disable admin completely or be on the hook for collisions. Okay, what else do we have? So we have a bill of materials update. I guess it will be also a lengthy change. Yeah, well, it's been going on for quite a while, but we're stuck on CloudBees folder at the moment. So CloudBees folder is, depending on a new region of structs, but it's not getting picked up in the bomb build, and we have no idea why. Is it in PCT? Yeah, it's PCT. Yeah, so there was one patch from JC about PCT. Yeah, that was another issue. So that was an issue causing flakiness. So there was some connection timeouts causing some builds to fail. All right. So our update center wasn't really stable over past weeks, and when update center was unstable, PCT would also fail. Yeah, that was picked up in one of the bomb builds, but it's not what's causing CloudBees folder to fail. I haven't looked at that yet. I could try to take a look, but PCT is quite complicated nowadays. I've downloaded, I've built the Mega War, I've unzipped the plugins, I can't even find that version of structs. I've grep for dependencies. The problem is the bundled version is being picked up and not the required version. So JC currently packages a Mega War here, right? Yeah. Probably he shouldn't, but yeah. So Mega War is one of the first implementations for PCT, PCT, which we're using for other purposes, but it's a bit complicated now. So I can take a look what happens, because we already had some issues with shady plugins before, mostly coming from test dependencies and from other definitions. Are we able to reproduce it? I can't reproduce it. I think I can reproduce it locally. I think, yeah, I'm pretty sure I was able to reproduce it locally, but it's been a while since I tried. The other thing is that the plugin has, on master they've changed using the bomb, but it doesn't look like it would have any effect. I don't think it's been released. They need to release it there? I think I pinged on the poor request whether they could release it just in case it helps. Well, it was trying. Yeah, I also don't think that it's going to change anything. No, it didn't look like it. Looking at the effect of POM, it didn't look like it changed. I think it might be workflow step API causing the CloudBees folder to fail, I think, possibly. So I can take a look at this poor request, right? Yeah, it would be great. I've been working on it for quite some time. That POM can be closed now. That test one. This one can be closed. This one, which should be... So the test on 290.1, so it reproduced the error and it was fixed in the next version of the RTS. But that's what helped me find where the issue was. You already commented that. I can ping from anybody about the release. Anything else about the BOM? Can you hear me? My microphone is going strange. You seem to be muted. I can hear you. Okay. There's a BOM 2.90 line as well, which is having similar weird PCT issues. So if you do have time, it'll be great. There are additional lines out, especially since a new LTS is coming. We had massive Trilliard API problems, but most of them have been fixed now. Let me add it. Where's BOM? So Antonio, do you hear him? Yeah, I hear him. Do you hear me? Yes. Okay, so it's like you don't hear team, only that. There is a broken connection there. So let's see what gets recorded to the cloud. Okay, so can we move on here? Okay. Yeah. So regarding the JCAS demo, I started to work in this old demo. I had four configurations called Groovy Hooks. So there will be reference implementation for system-read permissions and other things. So I will get it. It still doesn't work. Okay. Yeah, now I don't hear you neither. It's worse. Okay. Yeah, I'm not sure. That happens. So yeah, we'll just get this demo updated and hopefully it will be a reference implementation to whomever wants to implement it. So I'm not sure if we can go through this topic now. But yeah, maybe we could put it for the next meeting. We'll try it. Does it make a difference? Yeah. Okay, I'm on my headset mic now. So CIO. That's working and I can shoot your job using the COVID-19 app. Yeah. I haven't added the Azure VM agent. It's currently on a... I never opened it in public because Olivia never confirmed that he was happy for the credential IDs and such to be shared. That was kind of awesome description. Just check whether you're happy for this to be opened in public and then he went crazy just reviewing it all. Yeah. Okay. Taking our recent advisors, I can understand Olivia why he's not exactly happy because we had so many plugins announced for permission traversal and password travels and risks. Oh, he didn't say he wasn't happy. He just reviewed the poor question. It's just not really what I asked for. So it's working. I didn't add the Azure agent configuration because he asked me to hold off because he didn't ask me to hold off because it was quite likely that it's moving to AWS. Kind of just waiting... Just waiting for the AWS sponsorship at the moment. And possibly moving the infra folder to a different... or at least some of the infra folder to another Jenkins so that it doesn't have to have any infrastructure credentials that matter on there. Yeah. Yeah. I didn't put the infra credentials in as a folder. It's not very easy in Jenkins, but probably if it's not, then anyone can get access to the infra credentials, which isn't good. Mm-hmm. Just out of curiosity what's going to be used for credentials there because we have credentials IDs in the Jamel, but the actual credential is not using it. What? Do you mean how the credentials are populated or... Yes. So the credentials are coming from SOPS, which is a tool for encrypting the credentials in this order of private Git repository. Okay. So a similar approach to what was used in Nevergreen, right? Mm-hmm. So we use it for all of the services that are deployed on Kubernetes, so Jenkins.io and Uplink and LDAP server and everything. Yeah. So the real problem is credential IDs, right? I mean, I can easily move credentials IDs to SOPS as well. It's not a problem. I was just asking if it was a problem. So the problem that we need to reference some credential IDs in pipeline. Yeah, exactly. Because, yeah, if you just needed to cascade them in configuration files, it's trivial. Yeah. But, yeah, then I'm not sure which magic you would need to protect the credential IDs in pipeline. I'm not sure if it's worth protecting them or not. But I just asked the question. Yeah. Let's see. Anyway, it's great to have some progress there. I wanted to migrate it to a task for years. Yeah. It works. And people seem quite interested. I haven't really been able to join the information recently properly to talk about it. I'm traveling when the information is on, so I joined, but my connection is quite bad. Yeah. Yeah, of course, having configuration as code is the first step to have a kind of CI CD for the instance and also to enable external contributions. Because right now there is only a limited people who can go to the web interface and to configure the Jenkins setup. It's definitely not a reference implementation which we would like to promote. Yeah, and it's always been very hard to find out what plugins are installed and what not. Yeah, so the new instances like Jenkins for this environment, they're designed differently, but say Jenkins.io is still not too updated. Yeah. Yeah. Yeah, I agree. Okay. Do we have any other topics for today? So, plugin compatibility highlights and pending fixes? There's a pending fix for the file credentials. That's pending merge in the plain credentials plugin, I think it is. Matt's approved it, but he hasn't merged it. Yeah. I may not play try credentials plugin. So, file credentials I thought it's a separate plugin. Progress? Yes. Yes, this one return object and convert it if it's secret right. Yeah. I think we missed a bit. There was a fix in JKS was required as well to make this work. It's got an integration test that depends on the fix being released. Mm-hmm. So, yeah, pretty much similar to what we do for secrets in the Jenkins core. Yeah. Yeah. Cass tried doing a similar fix, but it didn't quite fully work a couple months ago, but this seems to work fine. Mm-hmm. Yeah, I agree. So, such a minor things here could improve the stability. But, yeah. So, see how Jenkins I.O. has this problem where the exported configuration had no credentials done it. Because of this bug, that was annoying and motivated me to finally fix it. Yeah. Export from functionality hurts. But, yeah, we did a great progress over the past year. Now the export configuration can be actually used. Which is good. Okay, any other hot topics before we close down? So, one maybe unrelated topic is Google Summer of Code. So, we have a bunch of projects there, but right now we don't have a project which would specifically focus on JCASC. Or if anyone is interested, we could add something. But, yeah. Historically, we tried to run JCASC project two times and every time it was quite complicated. But, if we take particular feature, for example, external configuration sources or something like that, it might fly. I'm not sure. Yeah, that would possibly work. But, yeah. I've always struggled with it because it's not really a beginner project. Yeah. Well, for me, many projects we completed over the past years were really beginner ones. It's a matter of finding a student who would be capable of doing such kind of projects. But, yeah. Yeah, I've already got my name against a couple of other projects to mentor, so probably won't put my hand up. But it could be a co-mentor possibly. Yeah. So, actually I was wrong. My project which is definitely related to JCASC is plugin integration manager tool. I need to fix that, I guess. Somebody. But, yeah. This would actually help JCASC because we still need to integrate plugin manager into the Docker image and maybe even into the Jenkins core. Who knows. But, yeah. This is a project which would help the ecosystem. You're going to struggle to get more into the Jenkins core? Yeah. I can imagine what security team says about that. Daniel wasn't king at 12th team. Yeah. But, well, technically if someone already wants to do that, there is custom work packages which can inject custom configuration and plugin manager. They're taking the project by Rik about packaging service and configuring custom work packages as a service. Maybe it would be one of the ways to get it injected. Yeah. I'm not sure. Let's see where it goes. But, yeah, I hope that there will be some projects around JCASC this year. Yeah. So, yeah, that's it from me. Anything else? Thanks a lot, Antonio. Thanks a lot, team. Thanks to you. All these full requests. Okay, thanks a lot. Bye, guys. Thanks.