 Okay. And we are live. Hi, everyone. This is Jenkins configuration as code status meeting. So we will sync up about configuration as code status and I'm going to give you this about that. So we have a really nice Wilco's and Nicola Deluf from the call. And yeah, also me, Oleg Mnashv. So really now, would you like to drive the meeting? Yep, that's okay. And as I mentioned before, before we actually started the broadcast, I don't have much to say, but I'm happy to drive after the Jenkins world in San Francisco, which I consider to be quite a success for configuration as code. I hadn't had a single hour time to look at configuration as code. First, I just couldn't look at it and then I had internet free vacation, which is perfect. But I'm back. And I could see in my mailbox and also on Gitter that there was a lot of things happening, some new issues and some new users reporting issues and getting help, hopefully. So this is looking good. Oleg, are you planning to edit something, the meeting notes while we speak or you want me to start that? Yeah, I can start the meeting notes. I'll share my screen then. That's great. So the agenda is as usual, we should go through, oh god, there were some action points from previous meetings, then we'll check the status and we have a couple of new things to talk about. So yeah, let's have a quick look at the action points. Have a look at tests. Is this the last one? What was it? Cannot install configuration as code plug-in. And I did not look at it. I don't know what's the status. Sorry, I completely forgot about it. Make sure the export feature has limitation. Okay, that's not the right sentence, but it was about informing people that export will not give them fully working YAML most probably. And then it was mentioned in the UI button in by Nicolas. And again, my action point might have been missed so kind of partially. And let's just move the documentation part and the first action point to new action points from this meeting. And I promised to take a look at that this time. Sorry about that. It was the Jenkins world fever that stopped me from doing that. So those are action points. Then the status. Last time we talked, Nicolas, you were mentioning a potential new release. Yeah, so we have a security fix Pentagon release. So the main issue here is that during the exports, we have some secrets being exported as plain text. So this has been reported in public both on GitHub and GitHub issues. So we already have a fix in the repo, but now need to release it. I didn't try the release already. I was investigating the plugin installation. So I have a pending request for plugin installation, which I'd like to be reviewed. And talking about plugin installations, we got some people to ask for assistance on GitHub. And clearly I consider this to be still pretty experimental and a bit hackish internally. So I used to recommend people who are using Docker images to better rely on external plugin installation. So probably the feature still makes sense in terms of country gas code and a higher level scope. But maybe this is not the best way to address this. What I have in mind here is a custom work package which already provides this feature another way. And discussion around this topic. So I'd like this to be at least fixed so it won't break country gas code. But I don't expect this to be featured complete without some glitches. Yeah, what we were discussing is having a kind of universal plugin management tool which runs outside Jenkins runtime and which generalizes a lot of existing plugin management utilities. So Nikola has created an issue in JIRA. I want to log in. Do you remember the issue number, Nikola? I was just checking. I discussed this with Koshiki yesterday, so I should have the ref in the notes. So once you're logging in, I just have a quick comment. When I use Jenkins in a Docker container, I rely on the way of installing plugins provided there. This install plugin is a SH script. But I know there is a lot of users that can't allow themselves to restart Jenkins and have downtime. Yes, sorry. And if you want to rely on that, you have to rebuild the container as far as I know. So that's why I still think that we should work on providing that feature in Jenkins configuration. At the same time, if there is some work, there is a plan to change the way of managing the plugins, then we should not spend too much time on adapting to existing solution if we may be forced to change it in the future. So I wouldn't put it on a super high priority to make it working perfect for now. I had issues with that too, and I will have a look at the PR you mentioned, Nikola. So we can have it merge and release when we're ready to release, but it should happen in a couple of days, if I understand correctly. Yeah, so we can do whatever we need as long as it's an experimental feature. So maintaining the plugin definitely makes sense. And when we have a generic engine from this task, maybe we could somehow generalize it. But yeah, this engine is also not nearly there. So the implementations are really different and the behavior is different. So we will need to do something. But yeah, since we all agree on that, we're going to review and merge this. The PR you mentioned, Nikola is handled latest by comparing installed version with the update center metadata. Is that correct? Yeah, so we'll have a look at that one. It will be some fix and then we'll have to, maybe when we meet again quite soon, we can have some extended discussion about it. But we'll find the right way forward. We won't probably try to do something almost impossible. If there is a chance, we have to change it in the future. So we'll see about that. Okay, so speaking of meeting, I believe you meant the day of Jenkins's code. Yes, that one too. Yeah, so I guess everybody on this call meets today. Yeah, if everybody else is interested, please feel free to join. There will be a hackathon and before the conference, there will be also a meetup. So yeah. Yeah, I can just a couple of more information. So it will be a two tracks event. We'll have some keynotes at the beginning that everyone can attend. And then you should decide if you're interested in the user track or if you're interested in hackathon track. The user track will be more focused on just Jenkins users, not developers. So a presentation how to do some stuff. And then the hackathon will be about fixing and improving configuration as code plugins. So yeah, I expect it to be good. Yeah, let's see. I'm looking forward to meet there. And by the way, speaking of hackathon, there is Hacktoberfest now. So it may be possible to add this hackathon to the list of Hacktoberfest events. And in Jenkins project, we have announced Hacktoberfest on Monday. So there is a blog post. Hacktoberfest contribute to Jenkins. And if you scroll down, you may see that configuration as code is one of the projects we advertise. So if anybody is interested to contribute to JCASK, just submit your pull request to JCASK itself to plugins, mark them according to guidelines and they will count as Hacktoberfest pull request. So you can get t-shirts, stickers and other cool stuff. Oh, then I want to contribute. Anyway, I've seen there was some, you were talking about it on Gitter about maybe leveling some issues. And I agree that it doesn't make sense to make issues just for the sake of Hacktoberfest. But I do expect to spend some time on the list of issues and maybe I will find something or I will, I will create something that is missing and I will use a, I will use a hackathon label and it can be both used for the hackathon a day of Jenkins or Hacktoberfest. So what we're missing is a list of new friendly issues. So we have them for some components, but there is no such status in JCASK. So technically I can take this example. I believe it should be close to actually this task, but he is a good first issue label. Technically what you could do now is mark issues which are simpler enough as good first issue. And then we have a kind of solution because here there is a good first issue. In Jira there is a new friendly label. So we can add links and these issues become a kind of examples of issues which can be picked easily by contributors. I will work on that most probably tomorrow during the day. Thank you. Just a second, I will also find Jenkins Jira label. Yes, so here there are new friendly issues and what I would do here is let's say it's labels in JCASK. For example, if you take JCASK compatibility issues, then there are two new friendly issues now. So we could use queries like that or there are queries for JCASK itself. It's something like that. So should I put an action item for you? Yes, and maybe in this point about new B friendly issues, you could add a comment that more issues will be labeled with those enough or I can do it. So if someone reads it, it's clear that we're not done. It would be really helpful. We also have a list from Google coding. We will prepare this list towards the application in September. As Jenkins project, we were not accepted, but we still have a list of issues, so we will be submitting them. Do we have any other topics to sync up on? I don't have anything to sync up on. As I said, I'm not up to date with what's happening, so I need to go through the list of issues. So unless there is an issue any of you wants to discuss, then I am more or less done. Nicola. Yeah, nothing much on my side. Not that much on my side as well. I was doing some patches for custom work packages and other such things, but it's not exactly in the scope of JCASC SOFA. We had the demo last meeting anyway. So I believe we meet again at the day of Jenkins and then the contributor summit at DevOps Vault to Jenkins Vault. By the way, when do you plan to arrive to Jenkins Vault? I'm just checking. I arrive relatively early afternoon on Monday. So I'm asking that I'm trying to organize a kind of mini hackathon on Monday. So yeah, if I find enough people, I will push it forward. Okay, if you arrive on Monday afternoon, it's probably not relevant, but let's see. But well, you can keep me updated at least. Okay, so that means we're done? Yeah, I believe so. So there will be ongoing discussions about JCASC support plugin, so about moving the features of the two plugins. Nicola, are you still working on the pull request for that? I just asked about moving code from JCASC integrations. Right, excuse me. I got some audio troubles. Yeah, so as you know, we have this support module, which is mostly some incubator for third-party contributors. So I have some pending pull request to get this code adopted by other plugins. And we also have, as you say, the integration tests that would make sense to be hosted by relevant plugins as well. So I'm not sure how much of them we have to keep in the Configure Scott project that can be debated. I think it still makes sense that we have some tests for for some major plugins. We have to get a correct balance. So I'm open to suggestions on how to manage this balance. And also, as you can guess, it really depends on how much plugin maintainer will approve adopting this code and doing some tests. If I recall correctly, we have three plugins. It's a role strategy, a matrix authorization, and the job-desert. So a role strategy considered approved once the code is done. Matrix authorization is managed by Daniel Beck. It was mostly positive, just the question of getting some spare time for it. And the credentials begin and job DSL is another story, but just wait for maintainer feedback. Yeah, it should be fine. And yeah, I believe that regarding, so regarding testing side, we still can keep the tests model as we have now in the plugin. Then what we created in May, there is an essential test step in Jenkins Pipeline Library. So this step allows running a plugin compatibility tester against plugins. So what you could do is just invoke this step and run the tests of other plugins with the new version of JCask. And I think that they have a JCask test, it will give you a kind of integration testing. You just, I can show an example of that. Yeah. So do you see my screen? So, yeah, Jenkins, Python library. So there is, yeah, essential steps. So it was created originally for Jenkins essentials. Now it's called the Jenkins Evergreen. We will probably rename the method as well. So what it does is just builds a word using customer packages again, then it runs ETH and PCT so that it runs against the version, the packaged versions of the plugins and you can manage what you actually test. I can probably find some examples. So why it's helpful that you don't need to move the code on your own. It's another essential step, guys. Okay, I can find it. Generally, there is a pull request, for example, to Stepler. Stepler is a web UI and the data binding framework in Jenkins and one of its problems is that it had exactly no integration tests with Jenkins. So we had some issues with Stepler a bit previously and here's a pull request. It doesn't quite work, but you can get the idea. So we had integration tests and then there is just a YAML definition, which says what exactly to run. This is, yeah, this is a jcasc setting. It's really obsolete. Yeah, here's an ETH. So we run some ETH tests as a part of CI flow and then we also run PCT. So we run tests against jQuery, icon, shim, pipeline, maybe, and etc. And yeah, we could do the same for jcasc if you want. Okay, makes sense. Yeah, once we get some test distributed in various plugins, it would make perfect sense. Yeah, it already happens. So people started adopting the jcasc. So even without incremental configurators, there are plugins which have their own test solid idea. Right. So the trick, I think, would be to filter tests so that we don't run the entire PCT framework for each jcasc change, but yeah, it's a kind of improvement. Anything else to discuss today? I don't think so. Nothing from me. I was trying to finish the meeting five minutes ago, but sorry about that. I think I'm gonna forgive you. But it went very efficient anyway. And yeah, as I said, I should be, I'm back online, so I will do some work and see you soon in person. Yeah, yeah, so see you. I'm stopping the broadcast and thanks to everybody who watched it.