 Okay, so we're live and I'm gonna start sharing the screen so we know what we're talking about. Share. So I hope you can see me in a minute. Then you have to confirm that you can actually see my screen. No, I can't see it. Okay, very good. So it's me, Evelina, John and Thorsten at the meeting today so far. We have a couple of small issues that I want to discuss, nothing really crazy, but the first announcement that I wanted to make is that I managed to get permissions for Jenkins YouTube channel so I'm able to handle Hangout on Earth from now on which is very good and I want to thank Oleg and the other people that helped me to deal with it very quickly. So that's it and yeah, Thorsten, you wanted to say something, right? Yes, I just saw that there's quite some PRs. You put one of mine already on the list, with the configuration as code, with the reload functionality and I think I created another one which just adds some table configurations and if I remember correctly, one of the contributors already approved it, but it's not being merged so I just wanted to ask what's the normal procedure over there. Which one is the other one you were talking about? I think it was for a key clock, AC2, the 707. Yeah, so now it is failing for some reason. The procedure is pretty simple. Whenever I have time to go through the PRs, I do it. I don't want to use the same excuse all the time, but I just had a couple of rough months when it comes to my apartment and because of this whole mess, the list of PRs is just long and waiting. So you did everything you should have done. Maybe in that specific case, it would be great if you could kind of re-trigger the build or have a look at why the How can I re-trigger it? The re-trigger is maybe a too big of a word for that one. You basically have to push another commit to that branch and it may be, I don't know, it's a small documentation change or whatever. Not the change in functionality, but the way it works now, you can't simply click re-trigger button, rebuild button. You have to push another button. I see. Are there any tests at all for the demos? Because I haven't seen those and I just added demos. That's why I'm asking. I'm sorry, I don't think I understand your question. If you have any unit tests or so for the demos folder because I just added files to the demo configurations. No, I mean, sometimes it's the build fails for some real reason and we just have to look at it. Okay, I'm going to re-trigger. Yeah, I mean, that's the easiest one. It fails again. Let's see. We have a problem. It fails sometimes. But this time when it cannot be built, I really can't see what's the problem. So I mean, that's not the one we usually had. It's a demo folder though. I mean, the most changes. So only markdown files you edited, then I guess just put up and we're still going. So it's just in the waiting list for it to be merged. It's going to happen. I mean, in the end, what I did there was just I played around with configuration as code locally and I thought it might be worth sharing those examples so that others have it easier to do. In regards to the test or the demos, there are some. I remember there was a PR that we talked about during the Jenkins world with some bats tests. I can't remember how far that went, but that looked very promising for basic syntax testing. And then there's the unit test during the source file itself or the source code itself. There are unit tests for all different kinds of configurations. Those ones I've seen. Yeah. But again, to summarize, I'm going to merge that PR since it's only a change in markdown files. So we don't expect the build issue to be caused by that commit. So that one will be taken care of quite fast. So there is this validate demos from Jenkins Octoberfest, but it's still working for years and I don't think there was any activity happening lately. So I may check with Victor if they are going to continue. Should we take over and what are the stages? Because I've seen that I've been there too and it sounded like a really great idea what they were doing. So yeah, a couple of small things that I wanted to at least mention is that I talked with Oleg a number of times regarding handling security issues and I promised I will be taking care of that. I got an access to security issues on JIRA thanks to Daniel and I will try to work on those whenever I have time. But those issues are not available for everyone. So it's not like any of you can just simply go there and pick up an issue, a security related to jacuzzi and work on it if you're interested in that. But I just wanted to make it clear that I have the access now so if any of you is interested in working fixing security issues, just let me know on Gita or email or whatever way you want to contact me and I'll try to make it happen. I again have to check with Daniel what's the procedure of introducing the new contributor to that. But I just wanted to let you know. I know if there are security issues now and if you're interested in working with security programs, just let me know. So that's one thing. The other thing is we were discussing the idea of introducing Groovy attribute or root element, Groovy script element in Jenkins YAML that will allow Jenkins to run Groovy scripts. And the motivation behind that was that we have in Ruby scripts working for Jenkins and there is a lot of people using those and there is a lot of people mixing Jenkins configuration as code and Groovy scripts because not all the plugins are supported yet. But one of the very nice big features is the fact that you don't have to restart Jenkins to reapply a new configuration after you introduce the change and it is required when you run when you use any Groovy scripts. So introducing support for Groovy script in Hellcast would allow all of those people that are using Groovy scripts to real their configuration without restarts and that's great. But we had some our reasons for not wanting it to be a part of Jenkins configuration as code plugin. And I think we all agreed on the way forward which was creating a separate plugin that will just provide support for that and can be contributed to Jenkins configuration as code. And Tomek started working on that but I'm not sure how far he is but we have a question and I would like to hear your opinion. So we in the repository we keep configuration as code support plugin and he was wondering if he's Jenkins Groovy plugin that will provide a functionality that I was just talking about if it could be a part of configuration as code plugin repository or should it be kept separately. And since this is my first Jenkins plugin I can't really say I know how it usually works and I was wondering if any of you have any idea or any opinion regarding the putting Jenkins Groovy plugin inside configuration as code repository or it shouldn't be completely separate. So anyone? It makes sense keeping it in the repository but not as part of the core Jcast plugin but it's possible to do it like the support plugin. Exactly so that makes sense to me because it only this plugin exists solely for the purpose of assisting Jcast so it doesn't make sense to have it as a separate plugin. So the way we have configuration is code plugin folder we have support folder we could have groovy folder and this is the place where he could keep his plugin. Is that what you're saying? Yeah. Okay I will just make sure we know. Part of that depends on who's maintaining it as well. So if it goes into the configuration as code plugin it would come so issues would likely come to configuration as code and it depends on whether you're able to support it or at least the the rest of all at least on triaging issues as well. So certainly it's simpler for users it's simpler for building a plugin if it's all in the same repo but it may add more complexity in the long run as well with people thinking it's part of the core and that it's maintained by the core maintainers where it may not be. Yeah I see your point. I see your point Tim and I kind of concur my point was basically just not to be part of the core if it's a totally separate plugin whatever but since it's basically just part of the Jcast it could be a sub component like a support but yeah true maintainer issues. There is already a separate configuration as code plugin for AWS secrets I think. So it's not the first specific configuration as code plugin that's separate. Okay I wasn't aware of that but whatever somebody has to be first movers. It's fine by me if it's separate. So you said that there is already a plugin that is kind of Jcast dedicated but and it's kept in a separate repository. Yeah it's configuration as code ecc I think. Configuration as code secret ecc plugin it's something to do with AWS and secrets. Okay. There's another secret source. We'll have to look into that. Heavy users of AWS. Yeah and configuration as code plugin support is kind of camped by the same team that works on configuration as code or at least originally so I think it does make sense to keep it where it is but yes that's let's not let's not create more confusion and if we have plugins that are being kept separately let's keep it the same way with the Jcast could be flagged in. So I'm gonna let so much know that's our view regarding that. And the configuration as support plugin that already causes a lot of confusion because it's not automatically installed but it's needed for a lot of work. It's needed for a lot of things. Hopefully it's not going to be required at some point. It will take some time but yes that's the way it was designed so make sure we help all the people that can't configure jobs because they didn't know the configuration as support is required. And maybe yeah maybe some documentation updates to make it not not clear that this one is most commonly required but installed separately manually. Clearly. Okay and then we have a number of pull requests or issues. First one is this allow three that I wanted to hear your opinion again allow triggering reload from local machine without authentication. So I immediately think about security when I see issue like that feature like that and yeah you address the security concern somehow. I can explain a little bit if you want because I created the PR. Yeah if you can very briefly go through that I think that would be great for everyone who may be listening an hour later. So basically what I'd like to achieve is to have the configuration as code within Kubernetes so if I use a ham chart to install in Jenkins and whenever I do a change to the configuration as code which is just a config map I'd like to automatically reload. For reload like it is now you need the now dedicated users and a token for that one which is not so easy if you just install the machine because you need the user already there and there's no way to automatically get a token. Someone explained away how you can get SSH keys but still you need to know a user and maybe that user needs to log in at least once so that Jenkins is aware of it which might be cause trouble if you're not using the embedded user database for example a few keys or whatever. So what it does it basically just adds a different endpoint which says reload and you can just post to it and it will reload the configuration but default that one is disabled so there's I introduce another property where you have to explicitly enable that one and only if it's enabled then you can call it without authentication and it's also checking if the call is coming from the local machine which should be fine in most cases. I mean the from resource is an example where they do it similarly. I mean they are not even checking for the local machine because they say okay you can enable that feature and all you can do is reload the configuration so maybe add some load to the instance itself for reloading but if the configuration is incorrect it will not be applied at all. Typically the configuration location is something which you control and if someone gets access to that one you've got different problems anyhow. So triggering it from localhost without that authentication should be okay in most cases I assume but I still want that people have to be opt-in to this option because if you're running the for example Apache and Jenkins on the same machine then triggering from localhost might not be wished because localhost could then be the Apache load balance in front of it therefore you have to opt in and if it's not activated then it behaves just like now and you've got a 404 not authenticated. Yeah I'm kind of convinced but team or John do you have any comment team you were commenting in that PR before so let me just have a look can you scroll down a little bit on that yeah not huge either way so there's another PR that's quite similar which adds a pipeline step for it yes so I'm not I think I think it's a big need so there's definitely a need for making it easier to reload configuration yes it's a little bit difficult now CLI can be a bit difficult it's quite often blocked on on your reverse proxy and so agents may not be able to access it so yeah there's definitely a need to solve here and whether we allow no authentication or not and certainly wasn't against them making it easier to remove so you don't have to include the crumb but I thought that was definitely worth making easier to use API but yeah I'm just not sure whether you should be able to do it without authentication it should be safe though because your your configuration has to be protected so I don't know whether it's a big issue to allow users to be able to reload it without authentication the only potential problem is denial of service I would say this is probably the biggest issue I think if the configuration is stored on the same machine as Jenkins as soon as you get access to that one I can as well just play around with the configuration itself and make myself an administrator so that's why it's not about it's not about the configuration it's about asking Jenkins to do all of its reloading there's a whole bunch of changes there which are probably slightly disruptive or so they're not there's causing load on Jenkins that may or may not be good if someone can just keep hitting their endpoints that's right especially if you do want to enable it but you are behind a reverse proxy which is making you localhost so that would be where authentication would prevent that sort of attack but typically I mean the load balancer is hopefully not on the same machine that's why I said for me it's an opt-in I live from I can hear some scratching and I don't know which one of you make the noise but please mute unless you talk sorry for interrupting please continue I mean there's a similar issue which is just proposing to watch for file system changes I suppose that would also be an option to implement it but then you have to pay attention if you've got multiple configuration file one has already changed the other has none do you retrigger then and the file system watching might be different on Windows Linux and so on and this one just gives people a little bit of flexibility how they want to re-trigger it security wise yeah I'm not I'm not strong either way so it's kind of down to Carolina or if you want to get any input from the likes of Daniel Beck or anyone yeah I am I think I will try to pull Oleg on that because he's he's he's very interested in the security of the plugin and for for well a couple of reasons so I as I say I am in favor and I do understand the need and I'm I'm unhappy that we don't have this this feature working well so far but I don't want to create more mess so I will I will take that to to Oleg who is a core developer and he he's absolutely makes sense and I mean if you decide that it would make more sense to have an API token for that one and for example just provide an additional track on the comment line where you specify the token you can only call that one with a token that would also be fine I mean I can easily make that adjustment if needed that is great to know and then like the meeting is being recorded so Oleg would be able to follow the the discussion if he finds time for that so I'm gonna check with him if he can suggest someone else to to have a look at it but thanks all for the for the input and well thanks for implementing that I'm pretty sure we can make it happen maybe with some small adjustments but let's see let's see how it looks so yeah I will just make no okay then we have a step to reload and this is is it the same functionality kind of it's just a different trigger I mean what they are doing is yeah it's running inside of the pipeline and yeah again team you are you are asking the security how safe is that uh already yeah so so my main problem with it was it allows you to override the target whereas I think if you're not in an administrative context you shouldn't be able to change it so I think it's quite reasonable just to allow reload because that allows sort of webhook integration if you're using a remote file you can just trigger a webhook which will just run and safely reload it but I didn't like the that the user could override override the targets which could allow you to change the pipeline and change the files change the authentication yeah yeah you can certainly change the authentication for Jenkins by allowing you to override the target okay but I mean um I think that one is basically the same comment as above so how do I do it here except you log into Jenkins when you're running it it's already it's slightly different security wise but it's still probably it's still good to get Oleg's view on it but I think it's I think that one's safer as long as you can't reload if you can't as long as you can't change the files like change which files are loaded yeah but I mean I like if you and I mean it can always change the content of the file like very radically and then reload it and then still you can mess up the configuration quite but then the security of the configuration file is I mean yeah it's not but typically I mean as long as the administrator has to specify the configuration location during startup I mean he's in charge to ensure that that's this is a safe place yeah the issue I see if you can override the location then it suddenly becomes an unsafe place where the configuration is the one potentially I'm happy with that PR if some changes are made that the target that you can't change the targets but I think it would be a good addition okay I'll put a comment in that one so so Daniel will know and what do we have here so that was there about plug-in plug-in developers being able to make sure that what they export is what they expect and that it actually works currently there is a little bit of documentation there but it's using a restricted API it's using the output screen so it's it's not the best API it's restricted and there is documentation saying you can do this but it's not it's not finished um and I also had problems trying to use it but I think someone else managed it worked for their plug-in so I'm not quite sure so who's that he's a student at a university working on a doing adding configuration as core support to a plug-in okay it means it by someone in the community yeah so I um there's an issue you reported and that's it for now you are you so sorry I couldn't quite actually all that sorry so uh yeah because I got a little bit confused so this is a this is an issue you're reporting and are you are you planning to work on that or are you just making sure you're aware of the issue and yeah probably a little bit of getting to the design of whether we want to keep using what's in the documentation there or create a new API that plugins can use it's easier to use um and whether it's something that we want plugins to be doing um because it's kind of unclear in the documentation at the moment mm-hmm yeah I mean in general we like some documentation updates are really required so uh we will we will try to I mean the world I will try to work on that too but thanks for explaining that and then I uh I hope we'll we'll get to that part um is there anything else that is not on the list that any of you would like to talk about so I take it as a no thank you so much for sharing your view on uh I'm going to close the meeting now uh I will talk to Olek when I have a chance when he has a time for that and we'll see where it goes and the next meeting will have a different time unless any of you feel that there is a need to to have a meeting earlier because whatever reason let's just so uh I'm going to stop the talk and I will thank you thank you for your time see you