 OK, it seems the hangout is live. Hello, everyone. We have me, Evelina, Olek, and John on the line right now. I'm going to start sharing my screen. Yeah, just please confirm you can see it. Yes. So we have a couple of pull requests and issues to talk about today, but we're going to start with Google Summer of Code update from Olek. So there is a link in the minutes of meeting. So just to quickly summarize, yesterday we had announcements from Google, and Jenkins's organization is accepted to Google Summer of Code. What it means is that this summer we will have a number of students working on different projects. And Jenkins's configuration in this code is one of the proposed project ideas. So if everything goes well, we will hopefully find a student. So the link I've posted is one of the projects specifically dedicated to configuration as code plugin. But there are more than 20 other project ideas, and many of them imply that there will be some configuration as code plugin integrations developed as a part of the project. So yeah, just a quick update. If you're interested to work on configuration as code as a student, check out this project idea. If you're interested to mentor the project, also reach out to us in the Gitter channel. And we will be happy to help you and to promote the project among students. And actually, this is something I wanted to talk about, because we advise all mentors to reach out to potential students, to potential audience. It doesn't matter where in Twitter, in blog posts, whatever, and promote their projects. Because yeah, like we experienced last year, it's really important to raise visibility of projects in order to find good students. Yes, when is the deadlines? I mean, I'm planning to write a blog post, but where I will describe in a very basic how to implement support for some of the plugins, and it's going to be the part about the easier plugins. But still, I can mention Google Summer of Code. So when is the deadline for posting such a blog post so it may still can make an impact? Well, it's definitely preferable to get it posted by the middle of March. But in such case, LA is better because if you post it LA, you have more time to communicate with students. But yeah, if you do it by March 15, I believe it's a good advantage. OK. And then I have another question. Some weeks ago, we were talking with Tomek Shandala, who wanted to provide support for groovy scripts in JCASK. And we advised him to create his own plugin, which happened. And I will mention it later. But he's working at the university, and he's working with some students running some classes. And he also has an idea to give them some plugins that are not working with configuration as code as a task, as a potential task. And of course, this would happen during the semester, not in summer. And I wouldn't like to have students that apply for configuration as code, as a Google Summer of Code, to prepare to work on a plugin that someone else is working at the same time. So there is no promises. We are not 100% sure that will happen. But in case that he goes with it and he has students that are interested, who should be the contact person? So we coordinate in some way. So we don't do that twice. So there are potential mentors in the list. And it would be the best point of contact. So fast and also, John, we are in the list. How it would happen. JSOC project ID is a Google Doc. And effectively, we can adjust the ID according to the real situation. So for example, if somebody takes, let's say, five or 10 plugins for the student work, we really appreciate that. And it's fine. So what would need to happen in this case? It would be nice to mark these issues as assigned in Jenkins JIRA. And maybe it makes sense to get it to come into this project ID document. So there's more. So it's like a make a JIRA issue for it? Yeah. So we have a dashboard. It's better to have all of them. And do they need to be created so that everybody will be able to work on the task and the grid and see the purpose of the plugins and the plans. So I believe it's better to just have this dashboard up to date. OK, yeah, I will come back now. So they use JIRA, but I hope it's OK in contacts. Some other potential mentors, not only me. So it's like I'm the only one who kind of have it. Yeah, it's better to just do it in Gitter so that everybody sees that. Yes, configuration of Scott Gitter has pretty high traffic nowadays. But it's still better to have a public track for such discussion. OK. Good. That's all I wanted to ask regarding the project. Is there anything else Oleg, you would like to comment on or mention regarding that one? Nothing specific. OK. And how much time do you have to stay on the line? Well, a few minutes. But yeah, I can actually just finish parking and then connect from the phone. OK. So I might be able to be back in something like 10 minutes. OK. Because there is this allow triggering reload from local machine without the authentication. And I would like to hear your comment on that. So maybe we can. So yeah, I'll try to reconnect in 10 minutes. OK, thank you. So we're going to pick that one for now and then, yeah. OK, then, yeah, on my way. Thanks. OK, see you later. See you. OK, so it's what do we have on the line because someone joined, Oliver. As we have just decided, we are skipping the allow triggering reload from local machine without the authentication for requests until Oleg joins the meeting back. And then we have another issue. This is mine. Intimate reload loop. And I don't know if any of you on the line is aware of the problem. But here is the thing. So I was, I had a number of thinking masters on my local machine. And everything worked more or less OK. But this was, I don't know, very light master. But I worked as a consultant. And I have customers that are introducing Jenkins configuration as code for their Jenkins instances right now. So there is a lot of people trying out JCAS that I have contact with. And very rarely, but still, a situation like that happens. They were informed that they should not mess with UI at all. So when they want to update plugins, they just update plugins TXT file. And they are using the install plugins as a script within their Docker file. So when they want to update the plugin or install the plugin, they just need to review the container, the image. And when they install the plugin, situation is quite easy. But when the update happens, sometimes Jenkins just goes up. The message says, as you can see here, Jenkins is fully up and running. And a couple of seconds after that, it says, restarting DMS requested by system. And it goes up and running again and restarting DMS requested by system. And I mean, I can't say it's going to be infinite because I didn't ever let this work for more than a couple of loops. But I assume it would be restarting like that for a long time. And this is very, very, but this is instability that we can't have. And I think some people were complaining about it in our issues on GitHub, but it was a long time ago. And it seemed that the problem was solved. But I'm afraid it was not. So when I was, I posted it, after I posted it, I reminded myself that some time ago, when we were planning to introduce, we were hoping that J-Cast will be able to take care of the plug-in. I was sitting with Oleg in the office, Pragma office in Gothenburg. And we were talking about the situation when you update the plug-in. When you update the plug-in, most of the time, you don't have to restart Jenkins. You just install the plug-in and it works. Very rarely it requires restart as far as I know. But when you update the plug-in to a newer version, you have to restart Jenkins. And then you can update the plug-in and restart it manually. So I had an idea that if we use J-Cast to managing the plug-ins and we update the plug-in, the Jenkins, the plug-in should detect the plug-in. The update had happened and restart Jenkins automatically. So that's why, but I mean, I don't want to put it on Oleg. I think I was talking to Oleg about this. But anyway, it ended up in a source code. So we have this plug-in manager, plug-in manager configurator, the Java. And we have a flag, it requires a restart. And then it requires a restart. It's true, then just runs the restart method from Jenkins. And I really hope that this is the part that is responsible for those infinite loops. Like for some reason, this flag is not being, or maybe it is being set to true properly. But I mean, it can't stay like that forever. So I was thinking first that we could simply disable the restart part. So we never do restart if you want to use. We already said that the plug-in management via J-Cast is not really recommended. And we can't promise that it's working really well. So I would like to just disable the automated restart and make it clear that if you decide to use J-Cast for plug-in management, you have to take care of the restart on your own. And that's an easy solution. And the other solution, I have my Jenkins app, yes. So the other solution was to add another option to this configuration is called root element. Allow restart. And by default, it would be true the way it is now. And then if you don't want to do those restarts, you would have to, say, set it to default. So this is a little bit more complicated solution because I honestly don't know how this part is implemented. But I don't think it's a rocket science. So I can figure it out. Or if any of you is interested, you can try that. And then we wouldn't change the default solution in any way. We would just have the flag to say that the restart is not allowed. And then that part is next to require a restart. We would also check allow a restart flag or something like that. So it sounds like the best solution with minimal intrusion. Yeah, OK. Well, to me, it really sounds like that we are hiding the root cause, right? I mean, I cannot see a valid situation when the restarts would go on and on and on. Perhaps one should be enough. So I presume that when the Jenkins boots up, it tries to do something out of plugins, discover the restart is needed, and it's probably a mistake, and try to restore and on and on and on. So what I would probably like to see of what my first steps would be, let's try log that we are restarting. And this is actually this thing, this Jenkins plugin configurator, who is actually invoking the restart because it's not clear from the log at all whether this is the Jenkins restarting or what else. And perhaps even logging which plugin is considered to be the new one or the one that requires restart, which should hopefully uncover why it's being restarted. I mean, yes, what you described would prevent it to go into the infinite restart loops, but we still don't know why. Perhaps there's some plugin that is incorrectly installed or there's some problem or there's some other problem with logic, but yeah. Yeah, I understand your opinion. I just know that there's a lot of people that are using Jenkins in a production. So yes, I wanna introduce a quick solution that will prevent them ending up in the state and then you can restore your job somehow from Jenkins volume, if you use Jenkins volume, blah, blah, blah. I just wanna introduce a quick solution that will not break anything and then of course not abandon it. So let's continue with troubleshooting on the site. Yeah, that makes sense. For a quick fix, it'll do it. But yeah, I concur with Oliver. There need to be some better logging at some point so we can actually identify the root cause and somehow eliminate it. Okay, so let me make a note as a quick solution. But the whole point in using Docker is not to upgrade stuff because then your images are immutable. You should actually build a new image every time you update your plugins and then create new containers based on the new image. Yes, but that happens when you use Docker to rebuild. So this is, yeah. Is this an issue in Docker-based Jenkins only or is it also if it's a generic warfowl on some random? I only use Docker solution, so I can't comment on that. The solution's simple. You have immutable images, create new ones. Don't go mess with updating stuff because if, but when the container crashes, you're back to square one. Yeah, but then you, yeah. So you use Docker volume to keep the data you don't want to look at, you don't want to look at the history. And then, I don't know. Like the issue is described under this link. So I think it would be nice if you could comment there. But the thing is that I can use it in one way. You can use it in a different way. Obviously. We allow it to work in a way that may put you in this unpleasant situation. So I just want to make it some safer solution. And then of course, try to find the actual cost. Sure, it's just the point. I like traceability. I don't like right now some container running in a state that I'm not completely in control of and unable to recreate just by starting a new one. But that's just me. Yeah. No, I see a point. Okay. So anyone wants to add anything else regarding that one? That sounds like no. So we had another, another poor request. And yeah, let's see what are the issues mentioned too. So sometimes ago, some time ago, we have decided that if we are using a folder as a configuration location, which means we can have a number of YAML files in this one folder, we only look in that folder and we don't look into subfolders. And yeah, for me, it was, I don't know. I was just testing something and I had my YAML on my desktop. And I know that's not the right way, but that's just one of the cases and there were some complaints from other people. So suddenly it was looking in all the subfolders and was finding YAML files that were not correct. And all like, not all like, sorry, Nikola had some ideas. And then we've decided that the way to go is just to look in the folder where that we're pointing to and we don't look into subfolders. And a couple of days ago, one of the users complained that he would actually want to have a sub director is searching for YAML files. And then his idea is, after I explained, I mean, explained, I just pointed out the previous issue. It was, he suggested that we could ignore the high hidden sub directories, which would still not solve my issue with putting Jenkins YAML on desktop, but I do understand that this is not really a proper way of doing that. So he created a pull request that was approved by Joseph and there is no comment from Nikola yet. He was just asked by Joseph an hour ago. But anyway, I would like to keep the current solution, but I understand that the user is asking for it because he has a use case for it. So any of you has any opinion regarding this solution? So allow searching for YAML in sub directories and just use exclude hidden directories. Put in another flag. Yeah, I mean, the same solution I suggested with... Exactly. Okay. Allow or don't allow, then everybody's happy. But that would have to be environment variable, right? Because... Sorry, can you repeat? That would have to be what? That would have to be an environment variable because you cannot put this as a configuration option into Jcast because it's about how to discover Jcast files. That's true. Nice point. Well, my idea was how about introducing something like end globs, right? So by default, when it is a file, it's clear, but it's a directory. Let's keep the old behavior. But what if, you know, customers specify a star or star-star pattern. So to decide whether they want to recurse or how deep they want to. Come on. So you're actually just saying instead of inventing some new magic method, use the standards? Well, yeah. I guess, you know, these glob patterns from end are sort of standard around Jenkins. So why not? But it should give us more flexibility without introducing any more variable, more modes of execution of current variables, right? So... Sorry. Olivia, is that you? Yeah, that's me. Okay, but you're not this reader. Yeah, no, no, no. Let me chime in into the pull request. Yeah, that would be great if you can comment there. So since he or she should know what we're talking about. Okay. So, I mean, you don't have to do it now whenever you have time for that. And the last thing I will mention was that, yeah, I mentioned Tomek before when you were talking about Google Summer of Code. Some time ago, just for the context, Tomek asked if it would be possible to introduce support for Ruby scripts as a part of Jenkins configuration is told. And his motivation was, of course, I can use groovy init scripts, but every time you change something in those scripts, you have to restart Jenkins because those are init scripts. And the great benefit that the configuration is called flagging brings is the fact that you don't have to restart Jenkins every time you change your configuration. And the decision from most of the people involved with the flagging was we don't want to make it a part of the plugin because that way we kind of provide a workaround that may become a permanent solution. So there is a lot of plugins that are not supported with configuration as called yet. And we're hoping that, well, Google Summer of Code students or just users that want to use the plugin or maintainers will fix the plugin. And if we give them the ability to use groovy scripts, then we may end up with less plugins being updated to work with configuration as code plugin. So we, of course, understand his point of view and we suggested that if you want to use it, just create a separate plugin that you can use with configuration as code. And I must say I did not have the chance to test the plugin yet, but I guess he did. And he released it. So, yeah, if you're interested, I just wanted to share the info that it's out there and you can have a look. But at the same time, he's the person that we, that is hoping to involve some students into fixing plugins. So he also understands that groovy scripting is just a temporary solution when it comes to configuration as code because we want to have a YAML syntax and very simple way of configuring changes as code. So that's just an information. And do we have Oleg back? Yes, I'm here, but I'm not sure about the sound quality. I can hear you very well. What about you? Sounds great. Okay. So we have this last issue. We actually managed to go through all the points in the agenda except this PR. And it's allowed triggering reload from local machine without authentication. We were talking about this at the last meeting and we've decided that, I mean, I really wanted to hear Nicola's opinion and your opinion regarding that one because I have concerns regarding security. And you self-assigned yourself as a requester Oleg, but since you haven't commented, I assume you didn't have time to look at it. Yes, I requested a review from myself, but it doesn't seem that I reviewed immediately. So do you want to have a little bit more time? Because it's not a bug. It's not an issue that we're trying to do in the future, but it's an interesting impact. So if in the upcoming days you'll have time to look at it and share your opinion, then I guess we can just wait with that one for you. Yeah, right. But please be sure I do not vlog the merch. So if somebody wants to merch it, Oleg, please feel free to go forward. Yeah, I know. I know you're not vlogging the merch. I'm really interested in hearing your opinion. And as I say, I don't think people are dying because we don't have it. It's a nice feature and it makes sense, but the security aspect is something that... Yeah, I would like to hear from you about it. Okay. Yeah, I'll try to review. No commitment, but I'll try to do it on the weekend. If you don't have time, then we'll just have to decide. But if there is a chance you may have time, then that's fine. I know. It's in my queue. Okay. So just a comment. Okay, that was all I wanted to talk about. Is there anything any of you would like to mention, ask or comment? A while ago, I... with a lot of help from Slide, fixed the log parser plugin. I'm sorry, we're almost half a year ago and we've been trying to pinging and calling everybody that actually can do something about the merge. Do you have any idea as to what's next? Sorry, I don't know if I understand you correctly. So there is a question on the plugin and it's not being merged? Yeah, it's the log parser plugin. It's not configuration as code directly, but we rewrote the front-end stuff to actually... So it works with configuration as code, but it has been merged. I remember we're part of it sometimes. It's just kind of annoying. That's basically what I'm saying. In November 6th, I opened the PR. Okay, yeah, there is nothing. I'm not saying you should do anything. I'm just asking, what can we do? I mean, you can always take over the plugin if the maintainer is not interested in maintaining it anymore. And I think... I haven't heard anything from any of them actually. So the only reliable way here is to actually request ownership transition if you're interested in this plugin. So yeah, Manuel Resen, you will unlikely get his feedback. You can ping him, but yeah, it's unlikely. Okay. Yeah, so basically we're screwed until somebody does something. Yeah, until somebody steps up and takes ownership of this plugin. Okay. Since you have invested so much time into improving it, you might be the closest person that actually cares for that plugin, but I'd like to encourage you to actually step forward and take over the ownership. Know that there is no long-term commitment for you to actually keep doing it for years. As you can see, people can just disappear without any problems, so it doesn't be a good way. Forward. Yeah, you can just take ownership and explicitly say that I take it for a few months to just deliver these features and to ensure that there is no regression to that. And it will be still a good contribution because yeah, it's mostly the plugin forward. Okay. I'll take it under consideration. Thank you for your advice. Yeah. If it helps, I can try pinging Manuel or you can try doing the same in Twitter because he usually responds to that. Okay. I haven't talked about Twitter or ping him on that one. Yeah. It's more reliable than GitHub sometimes. True. Okay. Anything else? There is one thing if I may. I've done some announcement on Jenkins developer list a couple of weeks back regarding using Jenkins configuration as a code for starting and testing fixtures for somewhat exotic use case and I would like to get more feedback from people just in case, I mean, to see how people see this variable. For now, this is part of a plugin me and my colleagues are working on but I have the intention to actually extracting it in form of a reusable test harness I would like to test how people feel about that if they believe this is valuable or something they would like to reuse or perhaps this is something that already duplicates something you guys have so I would like to appreciate some feedback from you. So I posted it on the dev list. It's a bit juicy. There is a short discussion afterwards so my preferred approach would be to give you a two minute introduction to give you up to speed and if you can come up with any kind of comeback it would be awesome. Of course, but do you want to do this introduction now or do you want to do it you prepare and do it at the next meeting? Well, I'm ready to do it now if this is the proper place. I don't mind. Oh yeah, I think it is. I mean, it will be important so we can mention later that there is this part of the video that may be interesting for others to watch on guitar or anywhere. So sure, I will stop sharing now. Are you seeing who may want to share? Oh yeah, it will be good. Let me see. Screen sharing. Yeah, I may need to reconnect again. My three. Okay. Yeah, I'll be back in a few minutes. Okay. Okay, so I'll try to start slowly for a while. There was a particular problem we tried to solve. One of them was that running Jenkins in the Jenkins Test Harness. Yeah, Jenkins Test Harness is not quite running Jenkins. Doing restarts and crashes and shutdown is not quite well supported and doesn't really work the way it does for production Jenkins. Another thing was that the class loading again doesn't look quite the way we want it to and we needed one more thing that Jenkins Test Harness is not capable of doing and is running multiple Jenkinses. So what we end up doing is actually running this Jenkins on the test as a part, you know, as external processes to the GUnit process. So there is no this internal in JDM Jenkins. So all the Jenkinses are running externally and we decided that Jcast would be a great tool to configure them for test. So what we end up doing is we come up with a dedicated rule to actually does that launching and dedicated annotation that specifies what's the YAML to set it up, what other plugins to install there and giving the fixture a name and in the test you can actually get it provisioned running as a sibling process to the GUnit and a number of these fixtures can be added for a test and then you can just pick it up as a fixture and you get a Jenkins server as a controlling abstraction that using the REST API you know, for the Java client to actually control the external Jenkins you're testing. This is the essential use case we're using. We wrote a couple of tests this way you know, with some smaller grids because it's running in the same machine so working with something like two or three Jenkinses works perfectly well. So this is essentially what we've got. There's a couple of other things to extend that. You can specify your own rule that is extending this one so you can actually change what exact plugins are being installed. If you're testing this for a particular plugin you don't want to repeat inject my plugin over and over again so you can abstract it away you can be a bit smarter you can split your fixtures into several categories it's called groups I guess or roles based on what role they're playing in your test scenario so you can modify these you can inject the particular resource XML different environment variables, Java properties you can actually even do some changes to the Jenkins home before we start it up etc. There's some additional flexibility to that so I'm wondering if there are some use cases when people would benefit from this or if there is a way how we can help you in something I mean basically the only one who come up with some sort of feedback with Jesse and he asked some modifications over structuring things somehow but this is the only one who provided any kind of feedback I'm really wondering if there is multiple people just to see if this as an idea is viable or not if this is worth putting time into or what exactly would the next direction be so I can provide feedback actually inside JCASC we already have some JCASC specific test roles but yeah they are part of the plugin test framework and what you propose is much about in terms of the flexibility so for me it's definitely the plus one to have it and to have it in shared library whatever so that it can be used right do you believe that it fits into the testing model into JCASC itself yeah so JCASC is organized as a multi-model project now and it's relatively easy to just add a new component which would be just a test library so for me it would be reasonable to keep it a part of JCASC I'm not sure what others think but yeah I don't see much overhead with that no I agree and it looks like it did a good job and then yeah I agree with Oleg okay so I'll try to evolve that a little bit further as JCASC suggested again I'll try to put this link into the meeting meeting notes so if anybody has any kind of technical feedback I would love to hear that and I expect to come back to this in a couple of weeks yeah that's great so I'll mention in detail that you were talking about that idea and the the link so maybe you'll get a little bit more feedback but you can move forward with that cool thank you very much last one speaking of Tencent tools a few months ago I started prototyping JCASC configuration tests that are based on Jinx file runner so I think it would be just a static on the top of Jinx file runner which can really apply configuration and reports results so a bit extended drive run mode if I make it to the time maybe I will present it at the next meeting oh that would be great okay so thanks Oliver and thanks Oleg anything else from anyone with it on the table and eventually these bulk fixtures maybe these test containers so that we can provision environment JCASC because JCASC is only a part of the equation if we talk about CIS I didn't hear you that well Oleg but can you I just wanted to say that having such additional annotations would be nice and if we get combined with token fixtures or maybe with test containers to be able to provision system because JCASC is configuration but if you want to emulate CISD system you also need to provision some environment so if we combine it all together in test automation it will give a lot more yeah definitely yeah that's pretty much in line with what Jesse has suggested so I guess as to the direction we're going okay we we're slowly running out of time because I think the meeting was scheduled for 45 minutes so anything else anyone wants to mention now okay so thank you all for joining thank you for a good meeting and I hope you have a nice day bye thanks Oleg for this topic yeah well thanks for any kind of feedback thank you guys bye