 Hi everyone, welcome to the regular jcask project meeting. Today we have three contributors on the call, me and my name is Rekhnachev because I still use cd foundation and we have Kim Jakob and John who also joined this meeting. I'll open the agenda. Okay, this is my friend. Yes. Okay, so we have quite a usual agenda. So we will talk about news about what's going on in terms of development and then just a bunch of updates which we had like the developer tools. You may understand correctly Sladyn is not joining today. Also October first updates and Jenkins OTS, whatever, which we still need to talk about. Okay, so let's go to the agenda. We've had two releases since the previous meeting. One is 1.31 and another one is 32. So, Kim, would you like to speak briefly about them? Yeah, so 1.31, I think it was the first release with the new beta JSON schema. And also there was a fix to allow check for null to override nullable by default. That was done for the SynaCube plugin, which has a progress open to fix the SynaCube compatibility. Yeah, it was maybe 1.24 or something like that. Yeah, something like that. And the other thing is the YAML, we're now testing almost all of our demos in the demo folder. We now got integration tests for almost all of them with the configure with readme gene at roll. Of course, there's a lot of changes there. Yeah, but there are still some public requests in the queue. Yeah, there's still three or four left. I don't know his progress, but this seems to be a lot of them. Yeah, the power of hardcover first. Yes, we can seriously thanks to Victor for getting it over the line because he gave us stuff that they can demo testing 20 years ago. Yeah, regarding else, well, there was just one change in this release about logging. The rest is about documentation, about dependencies. I guess we had a regulation here new to JSON, didn't we? Yeah, I'm not sure how that passed the build. And when I went to fix it, it was failing. Yeah, so this one, right? Yeah, that one. Yeah, maybe we need to promote, did it cause issues on the user side? Yes, it did. Yeah, there was a JSON class that got pulled in by configuration as code. That caused problems at runtime. Yeah, I'll probably drag it to the bug fix at least one. Yeah, but yeah, I still don't understand why that passed the poor request and master build and whatnot, but failed later. One due to binary conflicts. Yeah. Okay, so something quite good. Thank you. And yeah, regarding the rest, we have some progress regarding build materials. So now a lot of dependencies that should be managed by build materials for testing. So we don't manage plug-in dependencies on our own. And now we just picked up the new version of dependencies. And yeah, actually speaking of that, there is a repository Jenkins CI bomb. G-Cask is now a part of that. So if you do any kind of test automation with G-Cask, if you have an integrated set of plugins, you can use this repository build of materials in order to define the dependencies, for example, and then you get the updated set of plugins. G-Cask is now a part of this set. There should be a cool request to update to the recent version, I guess. So the build is already integrated. Yeah, bomb configuration has got from 1.30 to 1.32. And if I understand correctly, this is a tool which helped us to discover this regression because 1.31 was failing. So yeah, I hope it's not positive. So anything else about recent releases? And 1.32, is there anything else? I guess now apart from dependency and some documentation fixes, I don't think there is a lot of things there. Yeah, just a lot of long-level change. Yeah, this one definitely works with it. Yeah, we have a blog post from Slotting in the Flight, which will describe how to use the new schema. But even now there should be documentation within G-Cask repository. So those features. And yeah, here's a JSON schema which basically describes... Yeah, looks like it needs some SQDOT fixes up. Yeah, so I'll follow up with Slotting on that. But yeah, there are some guidelines and we hope that there will be some description how to use in ADS soon. Because yeah, the second piece of the project is to actually support ADS like Visual Studio Code. Yeah, there's a case study blog post that's pending that has instructions. We don't need to come in here as well. So yeah, I'll just take it from here. So okay, maybe we should just finish this part of that. So yeah, this one is completed, at least more or less. That's it, one. And there was another blog post from Slotting about just one report. Good news that we now really generate a schema which is consumable by users. Okay, let's go back to the agenda. So another thing we've had over recent weeks is Octoberfest. So we just started in the Jenkins project and it started pretty well. It's all across the organization. We had almost 40 cross-time contributors who joined to participate in Octoberfest. We had hundreds of cool requests and as you have seen in the study to release, Jenkins is not an exception. So Jenkins also got quite a number of contributions related to Octoberfest and actually Jenkins is a featured project there. So if you go to Jenkins events, Octoberfest, there is a feature of projects and there is a JCASC. And basically we welcome you to contribute to the plugin itself, to plugin compatibility in other components. And I believe we still have some new different issues. I definitely started running out of new different issues in other components. And yeah, it looks like here we also need to do something. So we basically don't have ones. So if somebody has any ideas in mind, what we could do. I thought we had the API docs while I was there as well. Maybe it's just not new different. Yeah. So it's Octoberfest, but it's not new different. Well, yes, there was a comment from somebody also in this Octoberfest part, but yes, there are no cool requests. So what we really need to do is to actually mark more issues as Octoberfest because it helps us to bring in more contributions. If we have good first issues, it would be ideal. But yeah, I would say that Octoberfest is a pretty efficient way to facilitate contributions. For example, I just spent one hour enjoying this follow around from Monday to file some issues and to teach existing ones. And just two days later, we have something like that. So one, two, three, and there is another fourth pull request which is in the fight. So it's a pretty good opportunity and if we can use it in Jcast, it would be nice. So if anybody is watching this call, please do so. Even if there is no ticket, suggest submit your pull requests, submit your demos, and it will be already a great contribution. Okay, any questions, comments about Octoberfest? Okay, regarding plugin compatibility, so again, we don't have a full list of changes, but we definitely have two important plugins which got Jcast compatibility recently. So first one, script security plugin, where we got, yeah, all right, it's an VK, I guess. I'll create a ticket for that. But here, there should be change lock on the bottom and here we have Jcast compatibility released on September 13th. Basically, now you can configure white lease for pipeline, including class loading, white lease, method white lease, directed from Jcast configuration as well. And yeah, it's a pretty good enhancement if you really need that, the way over there, but well, at least you can configure the things now. And the second plugin which got updated is script client plugin. So the issue we had there, but it wasn't possible to configure custom Git providers like JGit. And now there is a pull request which it supports all that. So it was contributed by Bobby Sandel. It's already released. So if you rely on JGit, if you don't want to use Git select, then yeah, you'll get a support for that right now. Am I missing any plugins in the list? The CloudBees Jenkins Advisor has a pull request and fly it. Yeah, I have it in the list there, low 10 fixes. Yeah, oh yeah. I think there was another one. Yeah, audit trail. It just looks a bit recent here. So audit trail is plugin, which adds some diagnostic logs for user actions and admin actions within the system, etc. So there is a pull request back here to JGas compatibility. Yeah, so this is a case where you probably use fill of materials. Probably I'll just comment right away. Yeah, I already added the same comment to the CloudBees one. And just because it helps. Yeah, I know of at least two other in-flight ones, but I can't remember if there are any other merged ones. Yeah, actually it's a good topic because right now it's really difficult to find. But did you get the GitHub one? Not yet. Okay, the GitHub one was merged yesterday. Okay, merged, but not released and hence I missed a bit. Yeah, I think it's just merged. Yeah, provisionally it was released. I guess that's cause yeah, it was released. So you're wanting to get, you still need to enable release draft within this repository. So that's why I missed a bit. Okay, just a second, let's find it. NPR 210 is the top one. Yeah. Okay, you've enabled release drafter. I enabled the release drafter, but we have a bug in the release drafter. So maybe it's just not working for the repository. Okay. Just second, we should come back to that because it's important. So yeah, it's still pending because it's not released. There's an error. Is there? Oh, right, sorry. So going back to release drafter, we have some plugins like GitHub plugin and Gradle plugins. So I'm not sure about GitHub plugin, but for Gradle plugin, so Stefan Wolf has tried to adopt the release drafter there. Basically, it didn't work. We need some investigation. We need some adoption of GitHub actions for that because one big issue with release drafter update that you didn't have access to logs of release drafter and you basically have no idea what failed. So here we have GitHub action for release drafter. And here you can see that it fails because you can't read proper plugin for entity. I reported this issue to release drafter. So it's somewhere here, but it hasn't been fixed yet. And I'm not sure what would be the right fix. Yeah, this one. So I'm not the only one hitting it. I'll probably apply just a quick hack to make it possible. But right now some plugins don't really work with release drafter. We have at least two components in Jenkins where it fails. Okay. So there it was related to the rework something. So there was a reward to support some changes. Now, welcome to JavaScript. So we basically have no other popular request because the payload for this incident happened correctly. It doesn't seem to be a critical issue to just put unknown here for what it was. We will still need to go through the release cycle. So I hope to fix it to forget how plugin and the regular because it's really important. Okay. Regarding color, I'm going with development. So we'll just put release drafter issues here. One thing I consider is to actually have a fore call for release drafter and using it as a backup action so that we can do our fixes quickly in the Jenkins project. So maybe I'll move the g-cast to this approach as well. Okay. So going back to ongoing development. So we still have systematic permission to request the Jenkins port. So basically the issue here is lack of reviews and we need to do something about it. I tested it locally. It works, but there are so many implications of this change. I'm not 100% sure. And actually I lean towards saying that it's a better feature. So maybe adding some feature flak or whatever so that we do not enable it by default because otherwise maybe it's not on the security issues in edge cases. What do you think about this team? It wouldn't be too hard. You just should be able to just have it fall back to admin if the feature is not enabled. Exactly. So one of the options here is, so basically we have this system. The other thing is that someone has to enable it for it to go on anyway. And we have a plugin for that called extended read permission plugin. So I wonder whether we could do it here. So one thing that there is already agreement to have a major release for the plugin. So we are both cutting 3.0. Right now it manages extended job read permission. So maybe we could integrate extended system read permission right there. Or maybe to your new plugin. Yeah, it doesn't really matter. Actually maybe, yeah, I'm not sure what would be the best approach because here we have this plugin and we have... Yeah, it's in my, I haven't got it hosted because it doesn't have any views or the call progress merged. Okay. So yeah, basically we could integrate it into this extended read permission because it sounds like a good destination. And again, we are going through the incoming major release anyway. So I think it would be a good option. Yeah, I can do that. I need to talk a bit with the usebot yeast, but... Okay, so something like that. So basically how extended the plugin works. A long time it was advertised as the smallest plugin ever in Jenkins. But basically it's still the smallest plugin ever. So if system property is not set, then the permission is enabled. So we could do same for a new permission. So basically I have system property, maybe inverse the system property so that it's disabled by default. And then we can use the reflection and whatever to enable it and still retain compatibility with other versions. Yeah, there wouldn't be too hard. So if you could move this code... I can talk to Baptiste and then we could see whether we could integrate it in such way. Yeah, yeah, and then I can just get rid of my plugin and just move it there as well. Yeah, it has a convenient generic name for that. So yeah, I think this one we can move forward this approach. Because yeah, well, it will address security concerns from this security team, or at least it will make them less impactful if something goes south. Because this plugin has a relatively low installation number and even there we can slither test it as an experimental feature. Yeah, okay. So regardless of the integration test and there must be something we already discussed. So Victor Martinez already indicated the future number of full requests. We still have some. So what do we have? Dependable makes the things even more complicated in the list. Okay, so we have GitHub demo, which is approved. So maybe if somebody else could review it, we could just lend it. We have some demo which doesn't seem to pass CI now. Yeah, it's because of that massive dependency list or Flaky CI, one of the two. Yeah, actually, maybe we should start the work now integration test because this approach is having a single file to the world. It's not going to last long. Yeah, I hope that the bomb would help quite a lot with that. But yeah, actually, what I'm thinking and the Jenkins bomb as well, once that's out should hopefully help even more. Yeah, Jenkins bomb as well. What I'm thinking that we actually have links rather than other income and credits. And actually, it includes some improvements for the vanilla image. So one of the things that vanilla image now uses the same deal of materials for player games. So what we could do is to actually use vanilla image and just to add additional plugins because what we need from Jenkins file runner is to basically verify our configuration. So if, oh no, there are unit tests. So yeah, it's more complicated. But we could definitely update the rule to just invoke Jenkins file runner and to ensure that the configuration passes there. And in such case, we can start unrevenantly dependencies club. But yeah, maybe it's a moonshot at the moment. I'm not sure. What do you think, Tim? Do we need to worry about that right now? I don't think we need to worry about it right now. They seem stable, unless it's that the actual Jenkins CI having an issue. Yeah, you have actions are working well. So you have actions do not verify windows for us right now, right? I'm not sure. If you get the poor request, it shows, I think. Here we are, actually we run on windows. Yeah. So yeah, I don't know if Jenkins CI runs on windows, but my RG can see I don't think RG can see I does. So I'm not too flaky and too slow. Yeah, we disabled Windows CI here. So yeah, I think that you can just rely on you have actions for now. Yeah, good to have the coverage there. So you don't, so that when you release, you don't have problems. I don't touch windows, but that's right. So do it. So VS Code plugin for Jenkins is something in development by Sladyan. By the way, do we have a GitHub link for that? Yeah, Sladyan said he invited me, but I lost the link for sure. Yeah, I guess it's somewhere here. Yeah, it'll just be somewhere, yeah. Yeah, there's GitHub issues for those. Yeah, we definitely want to host it. I think he was just trying to get something somewhat working first, but it would be good if we had it hosted, we could have all the issues in the one project in the organization. Currently, the issues are split in two places. We can have issues. We can use Jenkins. These are after configuration. We can use other bits like dependable. So yeah, dependable for JavaScript samples now. Yeah, there's a there's an issue to get it hosted. It just wasn't a huge priority. I kind of wanted to have something working before hosting, but... Okay, anyway, it would be nice. And it's definitely nice to get it hosted before it goes to the VS Code map, please. Because otherwise, it will be a problem. Okay, yeah. So, yeah, anything else in active development now? So does the SonarCube plugin has a progress to fix compatibility? Build monitor plugin has one as well. Hopefully get the build water on the merge zone. So, I'm not sure if we're having any build monitor. And the build monitor is in GenMolec. It's not hosted in Jenkins. Yeah, I thought we used... Okay, I was wrong. At least one, right? I was just about to say it all. Yeah, yeah, analog. Why do you host it in Jenkins? It's the top issue, unlike it have issues. Okay, I need to come in there because without hosting it on Jenkins GitHub, you cannot get the documentation published on the plugin site with more justification for the creation. I'm not sure whether it's a feature or bug, but right now we support on the agent and CI work. It was explicitly done in that way, I don't... Well, we discussed that this use case is spinning. And most of us agrees that we don't want to worry about it. Yeah. Well, it was just about a narrow security scope, I guess. Yeah. Well, yeah, when it's within Jenkins, your organization, at least we as Jenkins software needs, no, for sure, if we can influence the change. Okay. So, let's one. What was the reason not to use, not move? Oh. Historical, cloud beast, div, cloud, bitter. Okay. Okay. So, hopefully, we'll get it moved because then it will simplify the things. This plugin is quite popular. Okay. So, this is what Daniel is doing, I believe. No. Yeah. So, the jkask one says jkask in the title. I put it in the chat. So, one thing that this plugin, we will definitely need to move, not move. Yeah. It's a transfer. So, I'll just monitor that, but yeah, I think we can get it over the line. So, are there any other fixes for plugins which need attention? No, there was a regression and build failure analyzer from the jkask support. Yeah. But, it was fixed by board B, but it's not here at this. It's got a poor request for it. Yeah, this one. Okay, I guess it's going to end soon. Yeah. I think it's pending some tests. Actually, what I was thinking about plugin compatibility. So, before that, in Jenkins project, we had Java 11 support, which was helping contributors is getting the jkask. So, Java 11 connectivity fixes over the line. Will it make flow to have similar team for jkask? Yeah, makes sense. Have a public team that people can tag as well. Currently, we quite often get tagged individually. I can create one if you're fine. Yeah. Yeah. So, if both of us agree that we wanted, then I can create it. Yeah. John, would you like to join? Yeah, sure. And I will also talk with somebody from Cogniz. So, maybe they could also join. Yeah, because, yeah, one thing, it's about corporate, but yeah, maybe it's interesting to some, which I'll see that obviously now offers a jkask plugin as a tier two. I mean, the rest is available for the plugin. So, maybe we will get some contribution there from that side. Okay. So, developer tools, I believe we discussed that. October 1st, well, basically I talked about that already. One additional thing that we have meetups. So, for example, there will be meetups tomorrow in Switzerland. There will be two meetups next week in Munich. There will be a meetups in St. Petersburg in other cities. So, if somebody wants to organize a specific jkask hackathon, it is also because what I do, basically I put a jkask topic to every hackathon. So, that if everybody wants to work on that, it's more than welcome. So, if somebody wants to organize anything local, it should be really cool. Okay. So, we are slowly running out of time. And we want to discuss this wish list. I've got a laven. One minute. Okay. John, any updates from you? No, just they float basically. So, if there is nothing else to discuss, I think you can pull down the meeting. Maybe one quick update regarding ongoing development. So, two days ago, I started hacking support of external credential definitions. So, right now, we can define secrets as, well, there are ways to discuss them, to define them from vault, from Docker, from Kubernetes, source environment variables. But there is also a way to just define them right in the configuration file. In an encrypted way or in plaintiffs, if you feel brave, but the problem that encryption right now works on the, for the same instance. So, basically, should be here. Configure expert story, etc. The problem that secrets encrypted of four single instance. What I was thinking to do is to support the external encryption. So, for example, like we have here a date and whatever for Jenkins, we have Kubernetes secrets. Basically, it's a way to pass and code the secrets here. So, I was about doing the same project. So having to pass and code it secret. And then in a configuration or score context, you can pass, pass to the private key, which detects it. And then you can basically share these configurations between instances. And as long as you provide a private key for the encryption, you can use the same file on multiple instances. Something that I would like to share later. Very interesting. Yeah, but it's rather heads up. I haven't got to it yet. Well, I got it working. I need to have a prototype solution. Yeah, cool. Okay, so team had to go. And yeah, I think it's time to close down the meeting. Yeah. Yeah, so thanks. Long agenda today. Yeah, right. So yeah, next time we should cut it short somehow. Probably just buy somebody else's one or anything. Okay. Okay. Thanks everyone for watching. And again, all contributions are welcome. Well, it's not just some info requests. And we will try to help them learn it. See you. Bye.