 So, are we live? Let's see. Maybe we should be live all the time. Yeah, we're live. Yeah, finally we are live. Okay. Thank you for helping with the Hangout on Air, Liam and Olek. Welcome everyone who joined. We have more participants than usual here in the Hangout. And the video will be able to be watched after. Two, I think we can share the link on Gitter. I will just quickly check the message on Gitter. Okay. So, I'm going to share the screen. And I hope you can now see the Google Doc document. It's J.Cask office hours, minutes of meeting. And we keep all the minutes in one document and the document, like each one of you is available to edit the document. You're more than welcome to put your name under the attendees list the way John did it. It's the link. If you don't know where to find it, it was posted in the chat for this Hangout. And it was also posted on the Gitter room a minute or two ago. So, yes, feel free to update it. Not only the attendees, whatever note you want to put, everyone is more than welcome. We haven't had a meeting for quite some time. We've been either busy or I'm living in a forest and I barely have internet or electricity. But finally, here we are. And there are some things we have to talk about that I know about and I hope maybe you'll have more things to discuss. So what I want to talk about today is quickly to share with you what's my focus for upcoming months regarding Jcast and to hear from you if you agree or have other opinions. There was a lot of poor requests waiting that I promised to take care of in upcoming week. So we should expect a new version of the plugin quite soon. But, yeah, the one regarding support for Groovy scripting via Jcast cost quite a long discussion and it was a good discussion I believe and I would like to make a final decision so we all know where we're going. And then, yeah, Oleg mentioned on Gitter that there is a possibility to improve plugin in different ways during Google Summer of Codes program and we should talk a little about that. Any other business you might have, we can take after that. So let's start with the focus for upcoming months. For me, the most important thing is to extend the number of plugins we're supporting which means to make plugins compliant with configuration as code. Plugin and I know there is a number of features people are waiting for or some of the features require improvements and if anyone has a capacity and willingness to work on that, that's perfectly okay. But I think to get more people interested and involved and extend the community we have to make the plugin working supporting more plugins than it is now. Although I must say that I started using Jenkins configuration as code at the number of my customers and it's not a big problem to I mean a lot of plugins is already supported and many of the plugins are very easy to fix. So it's not a rocket science it's going well and that's what I will be trying to do mostly in upcoming weeks. But as I said, improvements and of course if we have some fixes, some bugs that make the plugin working but we of course will try to fix that. And then yeah, there is a long list of PRs waiting to be merged and there is a long list of issues that has to be answered solved or closed or explained why they have to wait so this cleanup will be happening soon too. Is there anything else that any of you would like to see happening in upcoming months? Perhaps I have a relevant question. I'm wondering is there somewhere a list of plugins that are waiting to be at least tested or the support to be added? I don't think so. The way the configuration is called plugins implemented makes it very tricky for us to know which plugins are supported so we know which plugins are supported or not when we check it. Quite often when someone tries to use a plugin and the plugin is not supported the issue is created and then the issue on the actual plugin that is not supported is also created and linked in the plugin so we were trying to have a compatibility page or is this something that is not being linked? So if there is an issue in JIRA with JKAS compatibility it will appear on the dashboard so we have some known plugins that are not supported yet. I'm trying to configure a plugin at my customer and I can see it's not working so I just try to fix the plugin and sometimes I just go and fix it and then I'm sorry to say but I skip JIRA because I'm not used to using that so a lot of things is happening in the background. It would be really great if you could change this in JIRA because it's helpful for JKASC users. I'm sorry I didn't do it I just jumped on the problem and tried to solve it and I will be more careful now and I will start with creating an issue whenever I fix the I try to fix the plugin and that's the JKASC compatibility label that should be used on JIRA Is that correct Oleg? Yes. So we have a number of plugins which are known to be incompatible so it's maybe 15 plugins right now I would say that there is no major plugins but for example there is lockparser plugin, there is lockable resources there is ownership plugin there is mask passwords which is also heavily used on some instances and regarding non-trivial integrations there is Garret Trigger plugin GitHub pull request builder which also needs integrations so there is a lot of plugins which actually require significant fixes to be JKASC compatible and this is one of the reasons why I proposed to have plugin compatibility as a JSoc project we will talk about them later. But yeah, there are still many plugins and our main problem that plugins which were created let's say before 2011 or so before we had proper data binding framework these plugins are most likely incompatible so a rule of thumb if the plugin was created in 2008 most likely it needs patches to be JKASC compatible I hope that answered your question at least, not at least it's quite extensive list and thanks for the reminder I'll make sure that I update the page too but this is of course a process, the plugin has to be fixed the plugin has to be released and then sometimes it's a yeah, sometimes it's enough but then sometimes I think we have some that may need to happen on JKASC site or not really, sorry, forget about what I just said yeah, so this is about the list of plugins that we already know that need integration, anything else regarding the focus for upcoming months that any of you would like to highlight? I have a question about the security process so in this autumn we had several discussions about following the Jenkins security process in JKASC and currently lack of this process blocks usage of this plugin in production at least for me and it would be really great if there are some action items completed on this front yeah, so it was explained to me and not only to me how to follow the process and you did that Oleg, so it's not like I forgot but those last months made me unfortunately not as much focus on JKASC as I wanted due to a number of issues but I will try to follow the process from now on and I will try to fix the things that were not taken properly last year, so yes this will be happening ok, thank you so let's ok, you put that in minutes yeah, let's move, I know that Tomas is interested in his PR and he is limited by time so I would like to move to enable separate for groovy script for requests for those of you who are not familiar just a short summary we have a number of plugins that are not supported we know that, we just talked about it some of those plugins can be supported with groovy scripts and the traditional way of doing that is using groovy init scripts and those scripts are being run on Jenkins startup as far as I understand and that means that every time you make a change in your configuration you need to restart Jenkins one of the great benefits of Jenkins configuration is called plugin is that you can reload configuration without restarting Jenkins, so Tomas would like to enable groovy scripts via Jenkins configuration is called plugin and at first it seems like a great idea but then to me, it's still a good idea to support it but thanks to the input we have under this pull request the issue proved to be a little bit more complicated and there are opinions shared by among others Nikola and Olek Olek is very against introducing the proposed solution me? no, sorry, Nikola and Olek I understand you said somewhere that he would be okay with the solution but maybe you agree with Nikola when it comes to some concerns and you propose some other solution here I actually took questions whether the feature makes sense and whether it should be a part of the jcasc plugin and probably we should review these questions separately okay so I agree with Nikola concerns that such a feature would impact the pace of adapting the plugins so and I understand you wanted to you said Olek you want to treat this to separate issues but I wanted to cover both so I wouldn't like it to be part of jcasc plugin I understand the need and there are some people that really want to use jcasc and well they are still allowed to do it with groovy script if you want to make it nicer and keep the reload part then you want to have groovy script supported by jcasc and I wouldn't like to have it in jcasc I would be perfectly okay with this as a third party plugin when it comes to putting it in support plugin we from the very beginning treated support plugin as a temporary solution and if we put more and more if we put support for groovy hooks in the support plugin then we will try to keep the support plugin for as long as we don't have all the plugins supported so it will be more long term than temporary solution so I understand we have a solution here and now we're saying it's great but put it in a separate plugin and not everyone may be happy with it but my personal opinion is that there are some three ways options to introduce the feature summarized by Tomasz and even if the separate plugin is your second choice it's like the idea that would be acceptable by all of us and since it's a community effort we try to be democratic so that's my opinion and anyone else wants to comment Oleg Tomasz there is one question about support to jcasc creating groovy hook which would allow to just append the standard groovy hooks to jcasc installation form would it be something you would consider for jcasc plugin? I won't pretend that I perfectly well know how it would be done when you say that it's a few lines of code it's not a great impact I'm just wondering how it would impact the concerns we have with lowering impacting the pace of adapting new plugins but I wouldn't fight against it strongly if we have a solution there is one comment though it's great there's black mirrors coming through in China wherever you're in I don't know if that was something being far more powerful comes with security impacts if we introduce the groovy hook would we decrease the security of the plugin and would it be our responsibility to make sure that it is secure I'm just trying to understand what Nikola wrote and I'm wondering if you have anything to say regarding that Nikola Oleg I'm sorry regarding the security impact taking the current state of security in jcasc it's quite complicated to say that groovy makes it work but theoretically groovy is unrestricted scripting language so if a maintainer allows passing groovy script then of course you can do anything but admins already can do it by setting groovy hook just ensure that in jcasc only people with the same admins can do that so if you make jcasc purchase a part of your continuous delivery flow for example you have an instance configured with jcasc somebody proposes pull request and it immediately goes to staging then if you permit groovy scripts then the malicious attacker can propose a pull request with jcasc configuration which would be doing some remote code execution on your development environment where the instance is promoted in that case it's a question of github permissions and yeah it's rather a matter of your pipeline I can find a use case but I wouldn't say it's a common use case what I'm after is that you mentioned that the security of the plugin is not great right now and I just don't want to make it worse I don't want to make it more complicated the simple question is do we risk you said you can't do some things because we don't follow the security process and I'm wondering if as introducing such solution would make it even worse solution risks so that's why that's why separate plugin is would be my first choice but I understand the lack of time to prepare everything alone Tomas if it's a feature if it's a functionality that more people would be after maybe it would be possible to find more people willing to contribute to a plugin like that sorry anyone can help me with preparation of the plugin how to start I so far written only one plugin in my life to Jenkins and it was few years ago good thing that in your plugin you actually use jcasc extension points so if you want to create a new plugin then technically you just use maybe an archetype there is a plugin developer guide for Jenkins users so you just follow this guide and then copy your code to the plugin and that jcasc is a dependency theoretically it should be enough to get this code running because it's a separate plugin okay we will try on Saturday so Oleg can you link the plugin developer guideline somewhere that would be great or you can put it in minutes and you know when you start just share a link the configuration is called Guitar Channel is a good enough place and maybe more people will jump in not everyone is at this meeting but I'm pretty sure you're not the only person that still deals with mixing groovy hooks and jcasc as a final solution so okay great so we're gonna keep this PR for now and I can summarize the decision we just made in the PR so it's clear and let's see how it goes with the plugin if it proves to be very complicated but I mean from what Oleg has said it should not be we'll just take it from there okay so it seems we have that one the next thing I wanted to talk about because I've seen the topic the discussion regarding that has started is jcasc and Google Summer of Code so Oleg can you briefly explain what's the timeline and what do we need from jcasc community to really benefit from Google Summer of Code okay so Google Summer of Code is an international program which includes many open source organizations Google actually sponsors internship for students and they work with open source projects in order to develop something and study something so students work full time for three months during the summer that's why it's Summer of Code and it starts early because we need to apply we need to do student selection and even now there are many students around coming to Jenkins channels asking about JSoc and that's why we started the project earlier and now we have around 15 project ideas published and we have more project ideas in progress as called Plugin Compatibility so as Oliver said there are known Plugin Impatibilities and my idea was to actually have a project which would just offer students to work on Plugin Compatibility take a number of complex plugins and make them compatible so this is the idea of this project and what we really need from the JSoc community is mentors because in order to do a project for each student we want to have at least two mentors the time dedication really depends on the student but it's usually several hours per week so it's quite high resource dedication for mentors but as a benefit you get a full time student and usually so that you can get a lot of the things done in your plugins for example this year in the previous year we had three projects and all three projects were quite successful and produced a lot of useful stuff for the Jenkins architecture like promoting Apache Kafka pipeline as YAML and configuration as code API so this is about this project idea and generally it just targets Plugin Compatibility and we offer students to select which plugins they want to make compatible so if anybody maintains a plugin and wants to make it compatible with JSoc you are more than welcome to join this project as a potential mentor and then we would be able to edit to the scope for students applying so there are two things that I would like to be clarified there is a number of plugins that you can basically fix with your eyes closed because it's a very trivial change would we remove those from the list of available plugins to be fixed because then it sounds like a very easy project and I think the projects in Google Summer of Gold are a little bit more challenging so should we review the list of the plugins and then just provide only the ones that require bigger effort to be available to be chosen actually regarding quick wins it's very important to have quick wins if you scroll down in the proposal you may see there are new friendly issues that's why we want to have these quick wins because it allows students to study infrastructure to do something and it's great to have them in the proposal regarding the final project of course we want students to focus on bigger things but it may be about areas for example a student may make a proposal let's make all the top related plugins I just make up the things but yeah it may include both big changes and small changes but we will be interested to somehow scope the project that's great because as you said those are quick wins so if you are someone dedicated with some hours during every week for doing that then we could increase the number of supported plugins significantly so this is great Jason shouldn't be a monkey work but some bits of quick wins are generally useful the other thing I am thinking about well many of us won't be able to provide support for a Gary trigger plugin so are you targeting also those specific plugins owners trying to involve them in the project or should we help you with that we would appreciate help with that because we have a limited number of JSOC mentors and work admins we will be reaching out to plugin maintainers but I believe we will be reaching out to them when we have students asking about this project and contributing something so if there is a student coming and asking saying that I want to have Gary plugin integrated then a person I know what to do because I know the maintainer I will reach out to him I believe that it will be a non-demand effort but if there are active plugin maintainers in Jcast community who maintain plugins not compatible with Jcast then you are welcome to just amend this proposal and highlight these plugins as recommended ones so for example I put ownership in to the list I used to be a maintainer of ownership plugin in December but I put it deliberately because I am a potential mentor and I would be interested to have ownership plugin fixed so something like that ok thanks for explaining no I think that would be a great help for the plugins so I don't see myself as a mentor because I always have time issue and I wasn't able to have a meeting for a month so I wouldn't like to commit to anything like this but whatever happens around the organization and trying to figure out what to do proposed plugins, contact people or offer some kind of I don't know, I will have time to test and find out every now and then for sure so I can be in some way involving I would be happy to be in some way involving this project but not as a full mentor capacity yeah right, it's perfectly fine and right now we firstly need contact persons so the project ID is fine if Jenkins gets accepted we will likely find more mentors but now we really need contact persons for students who would be able to answer questions and who would be able to provide some guidelines with these new befriending issues so it's not a big time dedication right now until May at least any help will be really appreciated here thanks for presenting it I think we already decided that we're using configuration as code channel for coordination about it at least for now let's keep it that way for you guys it will be just a number of newbie contributors coming to the channel which should be okay for now regarding most sophisticated projects I consider proposing a project for jcask configuration validation I would be interested to combine several other tools like Jenkins file runner custom work package etc in order to offer a validation tool which would be able to run config installation on a real instance even if it's packaged in Docker and Jenkins file runner so it's something I would be interested to do but I haven't proposed the project idea so far and in order to propose it I would be interested to find at least one other potential mentor okay I just thought of something so I was actually planning to write well not very long but still the blog post about those quick wins so I'm not a very experienced Java developer and I worked with Jenkins configuration as code but it's not like most of the implementation is mine so I think the blog post could be used as a nice resource for those who want to start with those newbie friendly issues so I would just describe step by step what I did, why I did and how did I know what to do and there are some materials like there is a post by Nikola we have some documentation in the repository of the plugin but I want to make it more like a story from less experienced person point of view so this will maybe help too I'll share it once I have it it would be really helpful for contributors and maybe if you have such a blog post we will definitely reference it in the project idea and you can also do vice versa so when you have a blog post you can reference JSOC project idea like say if you are a student we have this opportunity for example that can most definitely happen great I needed some acts above my head to write this blog post now it will happen ok that's cool so anything goes regarding Google Summer of Code nope so if there are any questions I am ready to answer them very good so we just have to be aware that we may have some more potential contributors coming to Gitter channel and asking questions ok anything else any of you would like to announce or ask or suggest well probably I should announce my availability I am not exactly a Jcast maintainer but sometimes I come to the meetings so yeah in December I sent a message to the developer about my limited availability in Jenkins community and yeah it's really limited for the next several months I will be mostly doing community outreach work like Google Summer of Code I won't be spending much time on maintenance of whatever and for example if Jcast needs fixes in Jenkins code we have several issues like chicken and neck and initialization and job definitions and other such things so if my help is needed for this area please let me know in advance I will see if I can schedule that if no I will probably recommend somebody else yes thanks for letting us know of course we will keep that in mind ok anything else anyone so I can just say that thanks to Oleg's help I managed to finally run the GPG command without errors so I should be able to run Hangout on errors soon so even if Oleg can't join we won't have to force Liam to run a meeting in the middle of the night or very early morning or something like that for him one thing you should know we created a JEP for YouTube permissions I will link it in the meeting notes so once you get your contributor license agreement integrated you can follow the JEP process request the rest so I hope it will help you yeah thanks for that I will also link my availability and then once you have the permissions hosting the meetings it's pretty trivial yeah now I ran Hangout on error on Pragma organization before so I know it works pretty well just but it's great the JEP with the details about the process so thanks for that so I think there is no need to keep us at the meeting for 20 more minutes if you don't have anything else to add of course Gitter channel is open 24-7 so you can bring issues or comments there anytime thanks for joining and I will talk to you in two weeks yes two weeks thanks everybody for stopping the broadcast