 Hello, welcome to the Jenkins Configurational Code Project Meeting. Today is August 12th, so it's just the middle summer break, so we have two contributors on the call, team and me. I doubt that we're going to have more participants today, so we will run a standard agenda unless there are more topics to it. Okay, so is my screen usable? Yeah. Okay, so summer break, we kind of discussed it, and yeah, we have a system with permissions coming from the next LCS, so there will be a lot of changes to this spring as a part of your UX hackathon and afterwards, and these changes are ending in LCS in September, so actually I had a question whether we could call it SGE or whether we need more to do that. Yeah, I think we should be able to. I think it was all in the 235 LCS, I think. Yeah, it was available there. Or did maybe Plugin Manager must start, maybe? No. No. If I recall correctly, the tool page has missed the LCS, and also they view plug-in compatibility issues, because I'm just logging into the epic. I think it was the agent configuration actually that missed the LCS. Okay, so let's take a look. So here in the epic, we still have some tasks which haven't been addressed yet, but the agents, your access for agent extender 3, right? Yeah. So 38. So basically, it means that we will have agent-read permissions in GA. Yeah, also plug-in compatibility. So here we still have quite a number of tasks to be completed, but yeah, to be honest, I don't think that it's really a blocker for GA. They're all minor and anyone can do them if they want to. All the coffees are needed out of there. And the force, I guess, so right now it still remains beta API, right? Yeah. Okay, so maybe this is something we, well, we can actually update the API retrospectively, or we can say that, okay, if this API didn't change to be called GA anyway, just remove the beta flag in the weekly releases. Yeah. Yeah, I think I saw what needs to do is just change the, you know, remove beta and have it enabled by default. Enable the convention by default. Yeah. Yeah, actually, this is a good question because extender 3.4 jobs is not enabled by default. Yeah. Well, I think it should be. So it was introduced in 2009 with a, for a beta period, as disabled by default, with someone going to come along later and enable it by default. I mean, one objection I previously heard is that the matrix or plugin looks bad if there's too many permissions. Well, what if you're working on UX improvements in Jenkins? Yeah, exactly. Yeah. So, yeah, I'm personally, I'm in favor of enabling them by default. And I guess enabling system read would be also in the same pull request. Yeah. So, so enable all three permissions in weekly. And yeah, I think that in such case it makes sense to say that the next LCS will be the LCS where system read becomes GE. Yeah. Doesn't change much in principle, but yeah. Gives more exposure. Chances are it's already enabled a lot of instances anyway. It's because of the updates make the call. I think they give it in storm. Yeah. Yeah, anything on the light. It's basically installed on any instance of updates because you didn't say that a plugin would automatically enable this. Yeah, I agree. So, yeah, for us, yeah, we still have some open items. I believe that we can just at least this topic for October 1st, etc. So hopefully some of them will be eventually updated. But yeah, personally, I agree with you that all critical stuff is there. I have a system read permission enabled on my instance. I'm totally happy with that. Yeah, maybe monitor rank would be cool, but yeah. Monitor rank is a bit tricky because it has management layers. It has redone the layers. Yeah. And gate basically provides all UI from external components. So it's not something like we can easily fix that. So the nicest one to do really would be that read only Jenkins improved pipeline view using a job. A little on the Jenkins pipeline view? Up one. 6214 in that one. That's probably the biggest, the nicest one. Yeah, but that's still an improvement. Yeah, it's an improvement. It's not. It's just a UI improvement. Okay. Yeah, so yeah, but I think that we can actually act on that. Yeah. So, yeah, maybe if you have a bandwidth to submit a pull request, but yeah. Yeah, I should be able to turn on the next day of time. Mm-hmm. So maybe it's better to actually do it in September so that we announce it when there are more people around just to get more feedback. But yeah, technically speaking, we can proceed at any moment. It's no rush. It doesn't really have any impact for months. All right. So yeah, for me, okay. So any other news? I think there's been one release. I'm not sure. So there's been two releases. So this one was, we haven't had meetings since 41, I guess. Yep. Yeah, 42s. Yeah, so here we have had a breaking change for secrets management, but at the same time, now you can provide the files and have a variable expansion. So it's a great step and thanks a lot to Joseph for doing that. Speaking of past and encrypted secrets, still on my plate, still in my hall of shame. There's been a few people asking about it every now and then. There's been a, the odd users came along asking about it. Yeah. Well, I hope I will get to that. Still, even if I do not do that, of course, from Joseph already provides a great foundation because, yeah, you have some support. So, and I guess there was no major changes this release in addition though, we've got some documentation improvements. Thanks to everyone who contributed to it in 1.43. So yeah, we had validation message fixes or some dependency updates, but I guess nothing super significant to talk about. No, not really. Just that there was a big core UX improvement broke our validation message on the buttons. Well, it's part of life, but anyway, it looks pretty well these days. Yeah. So I think that the plugin is pretty stable and we kind of keep polishing key, but it definitely does have a job. So I think that it's in a pretty good shape these days. So yeah, thanks for reminding me about releases. Okay. Anything else? Or should we go to ongoing development? Okay. So system read permissions, I believe we discussed it above. Well, Jinx configuration as code, there is not that much ongoing development, right? Right now. So we have a number of pull requests, mostly thanks to the Panda board. It's like you can merge the latest one. This one? Yeah. Okay. Well, we can merge it later, but I'm happy to approve it. Well, especially since it's in the test scope. But yeah, I think my objective right now is not to improve in JCASK itself, but the improvement user experience around it. So like system read permissions, maybe future integrations. But yeah, I believe that for JCASK engine, we will still have a bunch of improvements to deliver in the future. There's one PR year for me, the third one. That's mostly it's not an improvement. It's, I discovered probably a bug somewhere between JCASK and SnackML. And so here it's just to reproduce and open the discussion. We will discuss a bit with Tim about that. But yeah, basically, when you have a double as a class in your configuration, if you don't use string to configure them, they are initialized as new and not even with a correct value. Looks like a bug somewhere. I don't know many plugins using double. Do you have examples of plugins? Open source ones, no, sorry. So yeah, it was ready to open the discussion. It's not too, because I don't have really a solution. I just don't remember that and thought it was good to to let it surface somewhere. Yeah, so the string looks works well. And also, yeah, and so the main issue is for UX point of view, when you do the export of the configuration, you will get a double as you expect this form. But if you configure with the basically, if you configure your instance with what you just exported, it won't work. You'll get you'll get a new value. So it's a nice, well, it's a valid effect for sure. If it happens like that. Stipping through on a debugger or trying to find out where it gets lost. Because if you do it directly with Snake YAML, it works, right? So it's... I tried to create, I created the bug here because when I debugged it, it was somewhere inside Snake YAML, but I wasn't able to reproduce anything inside Snake YAML through the tests. So I thought that maybe it's because of the it's maybe because of the infrastructure, the class structure of the configuration, say for something like that. Because you have... In Snake YAML, you have a method to... I think it's the two-step constructor, something. Normally I put the description on the pull request, but when I was using directly Snake YAML, I wasn't able to go through that method. But I am able to reproduce on with Jenkins configuration. So for floats, I believe that the round trip works well. At least from what I remember, there was test coverage. So the first focus would be to actually just see whether there are any differences between float and double in the code. Yeah, maybe something like that, but I'm not sure. Is it that? Sorry? Do we see the floating format in the previous line? So, sorry, what do you mean? Yeah, scalar, yeah. So basically a case floating. So I believe that we have only one scalar for floating. So here it might be converted to float, and then it doesn't get converted properly. I'm not sure. But yeah. So for me, this part would be suspicious. Yeah, and that's probably mostly that. No one's really used double before. Well, stay tuned for big integers and other actively used types. Okay, so anyway, thanks Adrien for reporting it. No problem. Okay, so for plugin installation manager, do you have been working on that recently? Yeah, just wanted to get automatic updates. So get ready to do zero. Yeah, so 2.0.0 includes a lot of fixes to try and make it behave how you'd expect. So there were some minor bug fixes where things like previous dependency versions. So dependencies could pull in newer versions of plugins that you've explicitly declared. So that's just allowed now. Plug-in dependencies will always pull the latest version by default, which is how Jenkins core and install plugin script works, which means that you won't get out of date plugins by default. Yeah, you still have a chance to get a broken dependency tree in the current version. Yeah. Yeah, okay, that's a different issue. But yeah, it's net improvement for sure. Yeah, the biggest new feature in this is the ability to update existing plugins files. So you can ask when you look for available updates, you can output it in a machine passable format, either YAML or TXT, or you can just view it and standard out as well. That's good. Does it retain comments? Does it what? Does it retain comments in the diffs? No, it can't. So snake YAML doesn't support comments at all. TXT possibly it could. But yeah, comments are just not easily retainable. Well, I did investigate it. Yeah, it's a part of life. So yeah, maybe we could just actually add support for just comment field in YAML. Well, it would be awkward, but it's something we could use as a workaround. Yeah, yeah, and even in things like being able to pin it so it doesn't automate it and try to update it as well. So what it means is that soon we want to need a pomex ML input and depend on what? Maybe. Well, you still can't get dependable with this. That's the main feature is missing. You can set up a job which runs every week and updates them for you. We're just counting just whenever we update them we run the script. It saves like 20 minutes of painfully updating plugins. Yeah, that's for sure. Well, basically, that's what I did originally, but in my case it was just bash script with a lot of for AgExps. But yeah, this implementation is better for sure. And it's great to have it available. Yeah, or it's also showing available updates as API. This is also a good improvement. And yeah, make the latest by default. Sorry, we killed Palmock. No longer the penency. But yeah, now you use Weimock because yeah, personally I would kill all of them and just write integration tests with you. Still it's... You want to wait 10 seconds when the test starts up, sure. So when I was working on dependency resolution, I actually did some steps to improve, to create a kind of test training work. But yeah, I believe that Weimock with this implementation is definitely much better than I liked it was before. Ended up removing most of those tests in a follow-up anyway. There's only one test left which uses Weimock. Because the test became invalid when I rewrote it to resolve the update center URL correctly. Previously it was guessing updates into URLs based on the folder path structure which is getting removed. So they use version parameters to resolve update center correctly. Bug fixes. Yeah, that's good to know. Thanks for getting it over the line. Okay. Yeah, that's great that there is some progress there. So yeah, I guess we will need 3.0 eventually. But yeah, this version is much more stable. Many downloads have been, by the way. Could you just scroll down? Sorry? Could you scroll down? Oh. Yeah, you can almost see it. Maybe it's an extension that does it. So this is a draft. For the draft, there is no assets, but below, yes. 230 downloads. Yeah, maybe I have a vanilla browser. Yeah, I think my Chrome extension is adding it next to it. Must be an API for it. I think we can just do it here. That will probably send me the pull request later. Yeah, that would be nice. Because yeah, there are shields. And in shields, there are downloads for GitHub releases. Right. Yeah, there is a GitHub. Okay, so for all the releases, for example, why not? It's just Jenkins 6.0 and the installation version. I will send you the pull request later, but it should work like that. Yeah, 12,000. Cool. Okay. Yeah, but just a nice. Yeah, so nice to see that it's working well. And thanks for API, because it's what I actually need in JenkinsFileRunner. So in JenkinsFileRunner, I started integrating the plugin installation manager. So there is a pull request for that. One thing I stumbled is just a problem of plugin installation manager inside JenkinsFileRunner, because it basically had no parametrization at all. So you cannot pass custom updates and etc., etc. So here you can see that basically right now, all is commended out by defaults. And to be honest, I'm actually thinking about the alternate approach, just embedding CLI right inside JenkinsFileRunner. So splitting CLI and adding command plugin manager or so, and just embedding the library entirely. You should be able to set a custom update in terms of the config builder. Yeah, you can. Yeah. I just didn't do that, because if I do it like that, then I will have to manage all of it throughout the code. So I really consider options, just adding CLI and delegating everything there. Because for me, in JenkinsFileRunner, it already became quite complicated, because it has a single-level CLI now. So for example, there is a command which basically flips to the table and switches it to the CLI mode, etc. So having a two-level command line structure would be beneficial anyway. But yeah, anyway, I'm going to integrate it soon. I just switched to performance. But yeah, it's in progress. And for Docker images, have you already integrated the pull request? Yeah, I think it's waiting on you. Oops, plugin installation manager. Yeah, that's definitely waiting on me. Okay. So would it be fine if I do it tomorrow or after today? Because today we have a release. So just in case our release automation goes wrong, I would rather prefer to have it landed tomorrow. Please. But yeah, it's great to see the landing as well. Okay. Any other activities related to plugin installation manager? Okay. Yeah, Jenkins, fellow runner. You slightly discussed plugin installation manager. Actually, I experienced another issue which might be interesting to this group. It's related to Groovy Hooks. So I think these Groovy Hooks are that right now there are only two ways to pass. One is through Jenkins home. Another one through Bundy and Kaiser Resource and Warfile. Yeah, in the case of Jkasky, we have also a way to configure the think bypassing environment variable. And this way is not available in Groovy Hooks. And at the same time, Jenkins fellow runner cannot use either of these ways because there is no fixed Jenkins home at the moment. And if you don't package the Warfile using custom Warf packages, then yeah, it doesn't work. So actually, I had to opt out to just configuration as code Groovy. Because, well, it works for me. But yeah, I wonder what is the current status of this plugin? Because there is no active development. At the same time, it just works. So I'm not sure whether it needs any active development. I've never used it. Well, you write everything to me, Amal. In my case, I used too many EFs for that. I just customize and merge them all perhaps. Yeah, yeah. But yeah, finally, so I'm trying to get see a Jenkins runner over the line to have integration testing for Jenkins pipeline library. So here, basically, what I can do is see that I also switched to another packaging flow. And yeah, so the jcask now looks like like this. There should be Amal file here. Yeah, so basically just adding three files. But yeah, I wonder whether we need better capabilities and the Jenkins core if you want to maintain Groovy Hooks. Because my use case, well, it's not exactly an edge case. Just a patch. Okay. So anyway, in Jenkins file runner, I plan to create a bit more patches for better jcask support because I started prototyping with moving Jenkins file runner to CRDs and basically this image controller and other things. And yeah, then jcask becomes a bit more tricky there. For bill of materials, again, we have a dependency issue, right? Yeah, it might be on the Jackson 2 API one. Basically, yeah, clashes with our data format. Yeah, more coming from RTS Thomas. Yeah, I believe if I hit it in other component. Yeah, we hit it all over the place. Yeah, so basically, well, so one easy fix would be to just depend on Jackson data format and set the configuration as code. No, it would pull in fixed dependency. Inside configuration as code. Yeah, so if there is a use case for basically JSON management in configuration as code, you could just add dependency on Jackson API and so there would be no these issues going forward because Jackson API would be coming from bomb always. Can we add it to the test Thomas or is that not going to work? No, it's not going to work like that. That's the problem because yeah, well, technically you in Jackson in a configuration as code test harness, you can add the dependency on Jackson API plugin because in such case, it will be still consumed as jar and it will work. So the downside of that is that actually it could work. So I believe that we already declare dependencies and plugins in the test harness, right? Because we need jkask. It should be very, it should be quite light. So it checks in data point data format. Now we don't, well, we depend on the configuration as code as plugin there. Yeah, so basically we could add the same dependency on Jackson plugin and in principle, it shouldn't change anything for users of the framework, except the fact that if they use Jackson data format library or Jackson API, then they will have to resolve conflicts. But yeah, I believe that it's not a big deal. Yeah, I think that should fix it if we pull it in the test harness. Yeah, definitely. So basically it removes these two dependencies. So what we have system rules, flex mark. So this unlikely to conflict is anything. JSON schema. So this one may conflict, but I'm not aware about its usage anywhere else. So yeah, I believe that once we remove Jackson dependency, it should be quite sustainable. And you can take Jackson dependency from the bill of mosquitoes here. So you won't even need the version. The problem is that we need the next version of the Jackson one, which is the one that has the YAML version in it. Put on an update until we fix this. Do you really need it? Do we need the latest version? It's only the latest version that includes the YAML Jackson data format dependency. Oh, then yeah, then you will have to pin it for a while. Yeah. Anyway. Pin it here and pull it from bottom afterwards. But yeah, it will definitely. Cool. I've got to go on, by the way. Okay. So one topic I wanted to discuss today, if you have time, is about configuration as code seek. So just to explain the context, I've finally got to reworking cloud native seek. And what I would propose to do is to actually remove configuration as code from here. And basically merge it to the configuration as code subproject and call the special interest group. Because yeah, like we discussed before, I do not see so much difference between subprojects and seeks at the moment. So maybe I would rather merge it toward conflicts. Yeah. That sounds good to me. Yeah. So they think that basically it goes slightly beyond G-Cask. But for example, we already discussed plugin installation manager and other things. Because yeah, basically it's configuration as code experience for Jenkins users. Ah, so see you. Okay. Bye. So if you have no other topics to discuss, I think we. No, that's really. Yeah. Yeah, then I will just stop with the recording. And thanks Andran. Thanks team who had to run to meetings. And yeah, I will publish the videos. Thanks. Thank you. Yeah, thank you too. Bye. Bye.