 Welcome to the regular Jenkins configuration as code project meeting and day is April 22nd and we are going to discuss the project status and going development and recent news in the Jenkins configuration as code area. So basically we will be running the standard agenda and we have a number of participants on the call. So thanks to everyone for joining. Okay, so what do we have in our agenda for today? So we've got some news especially about the breaking changes in the Jenkins core. So team, would you like to summarize them? Yep. So there was a change in Jenkins core to remove the Java X annotations for detecting nullability. It turned out that the configurations code plugin was pulling those annotations from Jenkins core which caused configurations code to completely break if in most in many cases, an example being credentials but many other ways that it could completely blow up and stop working. We shipped a quick fix on the day we found it and we've got a cleaner fix coming soon. We basically re-added the annotations and configurations code temporarily and we've got a follow-up request to remove them but didn't want to have to do the testing at the same time just wanted to get the emergency fix out. Apart from that we have Jenkins 2.2.6 change the layouts on the manage page to have categories and if you didn't specify when you went right to the bottom and uncategorized. So now we've set it so that we're in a category and we're further up the top now. Apart from that I'm sure there might have been a couple of other minor changes in the release notes. Yeah just second time opening it on my screen. Yeah some Java doc improvements and some Q&A to the new issue dialogues that's a recommendation to try and bring questions to the get a chat first before opening a GitHub issue. Yeah we are using a new feature which is became available in GitHub a couple of months ago so now you see a GitHub chat here and if you want to add something else it's ultimately possible so if you're a plugin maintainer you can add even more links for example linked into your special interest group channels like mailing lists and whatever so yeah it's quality of life improvement for maintainers. And it just requires editing another YAML file. Okay thank you for this overview. Another Jcast related news that yesterday we had online meetup. There we had a presenter from EfiCode Pragma who talked about how to use configuration as code together with Kubernetes. It includes a Jcast plugin also integrations with job days sale also Helm as infrastructure is code layer so if you're interested for some example how to run a Jcast in practice you can take a look at this online meetup and the recording is already published. And speaking of that I have a topic for later about other meetups and log posts but yep we can discuss it later during the meeting. Okay any other news we are missing? I believe we had somehow recent Jcast compatibility patches in the Jenkins core thanks to team. Yeah so there was administrative monitors as support and it was very nice because I used it the next day. And there's been a couple of ones related to time zone and SSH authorized keys for the local security realm. So time zones are here? Yeah SSH authorized keys might not be there because it came in as a library dependency of Jenkins core. I think it's still there. We usually do that yeah allow SSH authorized keys to be configured with Jenkins configuration as code it was just a month ago so we usually put dependencies here as well especially when there is a change usable to Jenkins users. So in other related news Hedgico Waldpluggen has support for full path to the secrets. So there's the wish to access the full path because you might have a multi-team setup where you have the same secrets in different paths so it's nice to resolve in different paths basically. Yeah is your key vault a secret source resolver was released a few weeks ago I think? Yeah sorry HashiCorp Wald here this one. So here we get a full pass variables to G-Cask secrets. Yeah it's a nice improvement. Thank you and here we have time zone property users seven SSH authorized keys and the third one was update administrative monitors. Anything else about the news? Yeah is your key vault secret source resolver? Sorry? No it's in the jerky vaults just azure-k right to do zero sounds promising. It was released in like 1.9 or so but 2.0s to fix a resource leakage but we had to change SDKs which they didn't behave the same. Okay anyway it's a great improvement especially for example for CIGEN Kinsayo and other instances which are on Asia because now we could consume these features. There are quite a number of news and I believe there are more G-Cask compatibility patches happening in the background here and there. I definitely know that Adrian has released a new version of Malware plugin a while ago. Yeah yeah so that was the email there was a couple of fixes in Malware I think it was there. The TLS property that was not configurable because of a pojo issue so yeah it was a quick 132 to fix that. Yeah there's also configuring the user's email address for the local security realm as well. Yeah that's good so yeah we've got quite a list here and yeah thanks a lot to everyone who is working on G-Cask support not yeah there's a lot of other changes here and there but even this list is really impressive. Okay so should we talk about ongoing development? And the first item for us is of course system read permission. So how was going team? Good slowly so plugin manager and tool configuration got merged last week I think. I think plugin manager is in the latest weekly and possibly taller than the one before that. So that's great because plugin manager was a big one so that people could see what versions of plugins were installed and what updates were available. Yeah so also tool configurations yeah it's actually I'm just looking for other items. So basically we are on track to have something pretty useful in the next release right? Next LTS. Yeah next LTS. So we will have LTS baseline selection in two weeks and yeah by these two weeks you'll likely get all these patches in place because community ratings look pretty good and we still have a chance to land more fixes. Yeah initial admin monitor support landed in the last weekly as well I think. There's just one admin monitor and I've got five more locally that I just need to test. So I've done the changes but I just need to do some UI tweaks I think. So do you need any help with reviews from the team? Yeah I need log recorders reviewed and agent and cloud configuration reviewed. I think Daniel started on the log recorder one. He started reporting a couple of unrelated issues he's found while he's been doing it. Yeah what if we create a so currently your truck changes in the Jenkins Gera right? I most yeah they're in Jenkins Gera but I mostly just track them by searching for system in the filter here. Would it make sense to create a project on GitHub? Yeah I could do yeah. Yeah because okay then let's just do it because it might be useful since it implies changes across multiple repositories and not everybody uses Gera nowadays. So jab224 system read. Okay and I will also have something to be linked from the roadmap or from the job. Okay so public repositories you can scroll yeah well you will fix it later I should have okay I'll fix it later but after the meeting but we have a project so anyone is welcome to just link it. I will add all configuration as code developers as project maintainers. Okay thank you. On my side for system read permission I finally updated my demo to support it well I just bumped to the weekly not even to the previous LCS it works pretty well. Though I also started to work in a plugin manager to use plugin installation manager tool because I want to use dependabot and I don't want to use customer package in this demo. So yeah it takes a bit longer than I expected. So have you got a way of doing dependabot with the plugin manager CLI? Yes so how it works currently you can use maybe an HPI plugin to dump a list of plugins. So I added support of the plugins TXT from there and then I just generate plugins TXT as a part of docket build. Okay do you have a link to that? To be published. Okay because yeah I'm interested in that and I was thinking of where the customer package it was the right way or whether it was too much here for yeah so just to explain some context about it so there was a gap for bill of materials which we actually implemented so now you can use maybe an HPI plugin to generate bill of materials it's basically YAML. It's YAML in a different format which is not supported by plugin installation manager tool at the moment but still it's a foundation and I just tweaked the code to generate plugins TXT. In the future we just need to generate final plugin installation manager of YAML I believe. Yeah and we could probably just adjust the format that it takes to this if it's a standard if effort makes sense. Okay so I'll try to finish all my hard carry by the next week yeah firstly I tried to integrate plugin bomb but well it's basically based on plugin bomb anyway so we just combined everything together without the customer package. Okay and yeah speaking of bill of materials we finally got past our last bomb blocker and now we're on to another one yeah so so we got finally got up to 1.36 in the last bomb release and now we can't go any further. Yeah so it's a pain. What is the problem in this situation? PCT is always so PCT doesn't up so basically in script security on they have configurations code and configurations code test harness and PCT is only updating the configurations code dependency and not the test harness one and the test harness is trying to load the old snake email code and it's conflicting. So too long it didn't fit we need to update PCT to overwrite Jenkins test harness as well right? Yeah yeah the problem is that the recent update of Jenkins test harness also includes upgrade of HTML unit so it's not going to be easy because you update Jenkins test harness and after that everything starts breaking because of binary incompatible changes at least it's my suspicion. I haven't had any issues on upgrading HTML units. The only one is I had one fixed on the JDK tool plugin so JDK tool plugin actually started working after upgrading it whereas it didn't work without it. Yeah I'll try to release JDK tool this week. I wanted to do it anyway because it still depends on some older plugins so I'll bump the core baseline and release it. Just to clarify it's we were talking about the configuration of code test harness that was not being updated. Yes configuration is carried not the Jenkins test harness. Oh sorry then I confused everything. Yes it's okay. Bump of G-COSC test harness right? Yeah so there was two suggestions one was add a hook into PCT to update the JCAS test harness when updated in the JCAS plugin and the other suggestion was for PCT if it finds that it's updating a property to update the property rather than just replace the property with a specific version. Speaking of that what we could do since the JCAS is widely used we could just integrate it into plugin POM because for example what we can do plugin POM includes dependency management section so here we could add basically a JCAS test harness. We could also add a property which defines its version similar to how we do with other tools and then we can assume that all plugins which use JCAS test harness would be reliant on the same property name and they will write that in PCT. Would it make sense? Yeah possibly. The current guidance too that people include a property already for when they need the test harness. Well the guidance is really is use BOM where you can and then don't add one. True the problem is we had issues getting the latest BOM release out because we had to update everyone. So possibly we can yeah it's just difficult having a breaking change like this the snake YAML class path changes because normally there wouldn't be a breaking change so it would work even though they're out of sync. We might we would have had the same issue with the test jar I assume as well. Yeah and so the only real way to work it around is to shade the snake YAML without using the plugin but in such a case you will be responsible for keeping it up to date which is quite complicated. Also shading such libraries is always a risk because something may start broken. I'm happy and not maintaining it but it's just good to get over this hurdle some way. Okay so anyway thanks a lot for working on this BOM and finally we have BOMs for recent versions because before that we had 176 so many projects moved on and now we have 196 right? And now we're up to 222. We're up to the latest. Yeah I just missed that. Okay so thank you. I will definitely update some components for example JenkinsFabrana because they have been already immigrated to this BOM. Okay so let's move on then. Do we have any updates today? The pull request was opened about opened just over a week ago I think. Olivia was just completely focusing on the automated release though so he hasn't left us yet. Briefly mentioning it during the information meeting yesterday. Yes so yeah I think we will need to do that better sooner than later. Yeah corollous automation still requires a lot of things to be done. Yeah our new CI Jenkins IE instances is already configured this code but for CI Jenkins IE you need to apply more patches. So maybe in the second part of May you would finally get to that let's see. Yeah thanks a lot for staging that because it's definitely a great foundation work. I should probably separate out the other changes there. Yeah and I will be able to finally kill my development instance for playing pipeline libraries. Okay so secret encryption is external secret key. Quick update no updates but I still intend to do that. Pretty much the same for configurator API. I tried implementing that two weeks ago. I hit some issues with binary compatibility I cannot fix without reflection so I'm back to the drawing board for a while. But yeah one question to team Joseph and others so since we already updated core dependency what is the priority from your point of view? Do we still want to do that for the future? I don't know like most people seem happy enough bumping their core dependency as required. It seems to be less hold back and increasing core versions recently from what I've seen among other plugin developers. It used to be just target the very lowest version but people seem happier. We can always release lower versions as required as well. I was wondering if one I mean just going back to the last one on the jkast test harness for the bomb we could release a version with a snake ammo snake ammo dependency. A low enough version that script security could bump its core version to and we could just hack our way around it. It doesn't solve the problem but it would get us past this PR. I just take the stats for configurations code. 82% is over 2.1764 so it's pretty high. I don't think that many people are afraid of bumping. When they need to because we're only on 15% on 2.221. One question about that Oleg. Yes. I think I'm missing something. How is this related to a configurator API plugin? Lamping or not? We had a long discussion about configuration code API because current situation if you want to offer new API for other plugins then these other plugins will have to depend on the same version of the core as jkask or higher. So it means that now we ship jkask for the recent version. If we want to add a new API for example for configurators then you will have to update other plugins to be compatible with this new version. We don't have so many use cases for configurator API but at the same time it might cause problems at some point if we need to drastically extend it. For example we did some configurator API changes for the documentation generation when we were working on a community bridge project with Slayden and there might be some similar changes later. Okay so the idea would be to have a configurator API plugin depending on a baseline and then configuration as code depending on another baseline. Yes so configurator API model is conservative and updating on the one that's really needed and the configuration is called plugin basically rolling as it's needed to consume new Jenkins core features. For example new milestones, system read permissions and other stuff. Okay so so far there is no demand in that but yeah I think that at some point it will become a problem for us. Okay yeah all other plugins follow this approach like pipeline for example there is a lot of pipeline API something so plugins don't need to depend on the actual pipeline. Yeah okay so anyway it's this on my list I'm not sure when and yeah I can confirm that it's not that easy. Yeah I've tried before. Well when I did it in 2017 it was easy but yeah now it's more complicated to resolve these interdependencies. Yeah okay we'll deal with that somehow. Okay I put some items like roadmap updates, zoom accounts etc. Before we press it to that do we have any technical topics so that we can spend time on them? Adrian, Antonia, Sladyn? Nope. No nothing for me. The docs are locked for editing I mean is it still publicly available to edit? Yeah can you see the docs? Yeah I got to request it from the owner of the doc that I can edit. Is it still locked for editing? Let's see what are the permissions. So what has happened? Specific people can access. That's interesting. I guess this document is still owned by Abelina right? Can you change the who has access thing? Yeah I think so that's really strange sorry. No worries. Maybe Abelina moved it between Google Drive folders I'm not sure because before that it was publicly visible. Is anyone at Prachman with the link can comment? Was there another option? I'm not sure whether it's even on Prachma account but yeah so Google doc permissions. So I'll take an action item to contact Abelina. Maybe somebody else could contact. Yeah I pinged her on the Ghetto channel but I'm not sure if she'll pick it up. Even after your change it's still not visible. Really? Yeah I think you just made it visible to people at Prachma. Oh sorry it's my mistake. No there we go. Comment. Yep. So okay anyway we should probably move it out of our Progmas drive anyway. Yep that's working out by the way. Okay so I'll take it. Okay anything else before we press it? So we have 10 minutes left. Okay so yeah quick update on the Jenkins roadmap. So yeah tonight we have a first Jenkins roadmap meeting and we'll be working with special interest groups and projects to have it in place. So yeah it's quite long and we'll likely need to refactor it a bit. And there are some items related to JCASC. For example we have JCASC plugin compatibility, also system read permissions, built-in plugin management. It's mostly plugin installation manager tool plus integrations and distributions, then a PlugBall configuration sources which we discussed before. You put it in the roadmap. And basically that's it about JCASC right now. Obviously other stories may include some bits but yeah the number of stories here is quite limited. And if anyone wants to put something else on the list please do so. Because yeah this list is community driven. Are we missing something important on this list? I don't know. There is a lot of themes there. I guess. Yeah specifically for JCASC. Yeah so we will be socializing this roadmap later. It's still a work in progress. So there will be more items likely. Or less. Hopefully less but let's see. Okay. So yeah the next one, plugin compatibility highlights. I believe we discussed it in the beginning in the news section. Changing Zoom account for meetings. So one good news that we finally have a specialist account for Jenkins. What it means that yeah. So if you participated yesterday in the online meetup you already used it to run Zoom or webcast. But yeah what it practically means that now we can manage permissions to this account on our own. And we can grant more access to more people. So for example. Livestream. Livestream. Yeah Livestream as well. But yeah specifically for SIG meetings I think it made sense to migrate to the new account as well. Starting from the next meetings. Yeah definitely. I mean it saves something to manually upload the YouTube video later. So is anyone against? Yes. How do you get access to it? Is it possible for other people to get access? It's one of the reasons. So what is in my plan to writing new JEP for Zoom account? But basically all subproject leaders, SIG leaders etc are eligible to access that. So similar to YouTube. Then once it's approved I believe that we can just transfer access to your team. Okay so. I wanted to ask Joseph as well but he disappeared. So anyway. Okay so online meetups and blogs. Yeah. Yeah question to everyone. We have some new features about would anyone be interested to share something? Because yeah we are looking for content. Yeah I'm planning to write a system read blog. Both users and developers side of it. Yeah if there is any topic that requires a blog maybe even I would be interested in contributing. So do let me know. No. Yeah well basically any topic you would like to speak about is a good opportunity. Okay. Just think. Okay I'll think about it. Yeah thanks. Okay so it's community driven. We definitely don't assign tasks to create something. Yeah but if somebody is interested. Yes and specifically about Jenkins and Kubernetes. So we run a series of online meetups. And if somebody wants to present how to use jcask together with Kubernetes. It's more than welcome. Yeah I've also been planning to write a blog on Jenkins and Kubernetes with jcask and helm and I think I have started writing it actually. I think I was writing it a couple weeks ago. Great thank you and yeah if anyone wants, also wants to create something just do it. My problem was there was just so much content and you needed to slide it down into multiple posts. I have the same problem. Yeah sometimes it works. Okay so that's it. Any other topics for today's meeting? I see we're in the list. Okay if there is no other topics we can just close it down. Okay thank you guys. Yeah thank you guys. Thank you everyone. Thanks. Bye.