 Okay. Yeah, now we're online. Okay. Hi everyone. Welcome at this Moved Jcast Coffee Sours meeting. I started minutes of meeting for that one. The meeting we have now, I just forgot to change the date, is 29. Sorry. We have Oleg, Nikola, Su and Ion or John. I'm sorry, I don't know how to pronounce it and what's your surname. So if you can edit your name, I will put the link to minutes of meeting in the chat. Let's start with the follow up of the previous meeting. We were talking about the detaching configuration. Oh, no, that's the previous meeting follow up. Let's move to action items. Oleg, to add Jcast to the next Cloud Native Seek meeting agenda. Well, then I misunderstood the decision. So I started creating mailing lists, guitar chat rooms and everything. Then Oleg made me aware of the fact that it's not what we've decided. So I have a better internet connection now. So maybe we can make sure that we all understand each other this time. So what you're suggesting and I assume what others agreed on is that we stay at the Cloud Native Seek. We don't create separate, the configuration is called Seek. We can mention that we have office hours on the Cloud Native Seek page and maybe reports at the Cloud Native Seek if we are discussing something interesting during Jcast hours. Is that correct now? For me, whatever works. So yeah, that's what we agreed at the previous meeting. And the main reason for that was to avoid creating new entities. But if your preference is to go with configuration as code Seek, I'm also fine with that. Though it seems that Pipeline team doesn't want to be a part of the same Seek and they would prefer something separate. But even without Pipeline, system configuration there should be a lot of topics. We have this meeting and we can maybe include staff if we, like regarding group looks for example, if we need. But I prefer your idea, especially now with upcoming months. I'm going to be busy. We are all quite busy. So let's stay with Cloud Native Seek. I will just update the PPR. I created updates on Cloud Native Seek instead of creating the new one. All the people that I have created in your mailing list. Sorry for the spam, I will get you. So they will be Cloud Native Seek meeting next week. It's my plan. So if you're interested, you could just do a status update there. I'm going to make most probably I will send a mail with the update because if everything goes according to the plan, I'm going to be somewhere deep in Swedish woods, Swedish forest without the Internet. Okay. So yeah. So I'm going to fix the mess and send... Sorry and send the update to the Cloud Native Seek. Okay. The next section point was, yeah, Alexandra was working on two issues in one PR. One was regarding introducing text fields under configuration as code subpage in managed Jenkins so we can provide a new configuration source. And that was my request. I was having trouble when I was using Jenkins installed locally, like just an app, not a Docker container. And since I want to work on a blog post where I describe two use cases for running Jenkins as code and I want to make it as easy as possible for people that are not very fluent with terminal yet. They are just starting. Then I really wanted to have a possibility to manage the location of configuration source via UI. And it's done. The other one was dry run and I don't think that one is finished. We will hopefully discuss that today. Then I was supposed to release new alpha or that was a long time ago. We in Pragma had messed up something with our release mechanism. So Nicola released a couple of times alpha and then release candidate one. And last week, mess released, release candidate two because we wanted to have this thing implemented that Alexandra, the UI text field for configuration source location. So that one is done. And then, oh, yeah, I did not discuss merging to master. Maybe there is enough of us now at the meeting so we can talk about that. And somebody to fix the master branch while master branch was fixed. So we're more or less good. Oleg, you were attending the previous meeting. Is there anything else you want to mention regarding that one or should we move on? Nothing specific from me. Okay. Very good. So, well, the next finding in the agenda is release status, but it's basically the jcask status. We had planned to release official one zero sometime in the middle of August. It didn't happen. And that's not a huge problem. But we definitely want to have it before Jenkins world sometime next week or the beginning of the following week. That's my opinion. So I'm looking at the release one zero milestone. And I hope you can see that. We only have one must have issue. And actually, when I looked at the issue, there was a discussion about it. And then Nicola lowers the priority and Oleg put it back to must have. So I think since both of you are present, maybe we can discuss if we really must have it in the release one dot zero. Well, if you don't have it one dot zero, then potentially you start breaking plugins dependent on your plugin when it goes beyond one dot zero. Removing a library is a backward and compatible change in Jenkins terms because there is no plugin installation. So if you do it after one dot zero, you potentially break something dependent on jcask. And it's hard to predict what exactly you break because they maybe just rely on snake Yamal and taken it from your plugin. Nicola, any comment? Yeah, I agree with Oleg on the general principle that actually we don't have any pros and any mechanism in Jenkins to isolate plugins bundle dependencies. Yes, so I was thinking that his main concern was that once we shed snake YAML, if we have reference in the API, then it will change the API. That's the reason I was lowering priority because we don't have any more reference to snake YAML in the public API. It's just a bundle dependency. So for sure if we have some other plugins that rely on configure code to get this dependency in class path, which is probably the worst way to manage dependencies, then there is some compatibility risk. Yeah, right. So my preference would be to either shade snake YAML or maybe to detach it to a separate API plugin. The detaching to API plugin doesn't help much because the only reason why we do that is compatibility. Yeah, snake YAML doesn't use to be backward compatible so we can use this API plugin approach. Yes, so my preference would be to shade it anyway. Alternative option would be to just add section about that to developer documentation so that it's explicit that snake YAML shouldn't be used from the plugin. It won't help much because people will be still implementing that. They will be potentially getting into upper bound dependency issues if the YAML plugins try to implement jcasc and also have their own YAML functionality. So yeah, shading before the release looks like the most safe approach to me. And are you able to estimate how big is the issue? How much time it can take to solve it? Hard to say. So if you are lucky it's just five minutes. Okay. If you are not lucky maybe five years because it really depends on how snake YAML is implemented internally. If it does a lot of reflection, calls to its own classes then you won't be able to really shade it. Okay, so if we added this must have then we may end up releasing in five years. Well, five years, yeah of course it was a joke but yeah the idea that it's hard to estimate what this task would take. So do you have time to have a look at least to be able to estimate or it doesn't really make sense? Not before Jenkins World. Okay. So let me have a look at it. I mean I'm not saying I'm going to do this but let me have a look at it and let's... Yeah, I will talk with Mass maybe with some of you on guitar. So I understand that's the most safe approach and... Yeah, so there are several examples of shading libraries in Jenkins. So for example in Docker 3 stability and yet another Docker plugin etc. The main problem that currently you cannot shade libraries in plugin form. So you need to create another model which just does library shading and then to add it as a dependency. It's a bit weird but we haven't fixed the agenda yet. So that was my question because I tried to use this approach and doing so. I just can't have all modules open in my IDE. Because the path to shade the package isn't included in GenBrain IDE so that's a bit confusing. Yeah, I'll paste an example to the chat. Okay, so it's a problem for IDE of course but mostly it's a problem for maybe in tooling. But yeah, at least in the case of JCASC you don't need to change the project structure because you already have multi-model project. Okay, so as I said I will try to have a look at it and continue the discussion at Gitter and we'll see where it takes us. So that was the only one that we had this must have in release 100. Does any of you see any other issue that or maybe we don't even have an issue for that but something that we need before release 100. We have some issues that are bugs. I think we need to scrap issues because this list we mostly created a few months ago. So it may be just obsolete. Yeah, you mean the Milestone one? Okay, so let's maybe start with what we have here. That one, we had a workaround for that. Yeah, am I still assigned to it? No. Okay, just to make sure. So this is still an issue and it should be solved before 100, right? Yeah, it should be solved before... No, actually it doesn't. It's just a developer issue. So it doesn't really block any kind of release. Okay. Yeah, and I guess that once you go to 100 release you will remove beta notations from your APIs so that this issue will be likely solved anyway. Okay. But what's the solution for that? This is the workaround we're using now, right? Yeah, so the workaround effectively means that you run with a new agent to score a version. That's it. That's okay. This is documentation that one we just discussed. This getting started documentation. It is kind of what I will have in my blog post. So once I work at the blog post I will improve the documentation. At least the part I want to work on. That one I guess here you are still assigned. Yes. So I contributed some pull requests to error propagation. API was all reviewed and improved. We could close that. One point that I believe that the configurator API is a must for the plugin. So yeah, I consider it as a part of that. Since there is a decision to not do that, I think it can be just closed. The issue. Yeah. So main things have been done. Nice. Thanks. Support configuring Guillermo part in manage Jenkins. Oh well, this is what Alexandra was doing. And then preparation description. That's also documentation and it will be part of what I was working on. And this is just a cosmetic change in the configuration code text in manage Jenkins. So that's a piece of cake. And then let's see what we have here Jenkins down after installing planning. Yeah. But it may be not related. Is that what you meant Nicola by this comment? All right. Was this one I know I'm missing context to get more information on what's going on. Plus one. We need more information here. Yeah. So that one is just from two people. Yeah. So currently all custom configurators should provide schema jelly rate. And it's missing. Is that what you think or? It's my guess. Yeah. Anyway, that's something that should be solved before the release one zero. Great. Cannot install. Can you scroll down? I'll just open the tracker in parallel. So cannot install one concurrent modification exception in the reactor. It looks type and not present exception proxy. So this is an issue with class loading. Most likely binary conflict. I think we should at least invested. I mean, we should invest. Maybe we'll end up from the milestone. But for now it sounds like a ban. Yeah. Maybe we should discuss a wide efficient topic. So we have a plug-in installation support in jcasc. It's announced as a better feature. So if we keep it as a better feature in one zero, then this issue is probably not a problem. I'm sorry. If we keep plug-in installation as beta in one zero, then what? I did not get the last one. All issues called by attempts to install plugins with jcasc won't be a priority for us. Okay. And it is possible to keep them. Okay. But the inside configuration is called plugin management. That's not plugin management in our plugin site. Maybe for me it seems to be related. But maybe I'm wrong. What we will do is that this person was trying to install configuration as code and got an error. So yeah, there was a failure installing configuration as code support. Well, from what you may see in the log, there is a plugin which needs to be updated. Objects authorization. So yeah, the real problem that he gets into issues when there is a restart. So it's not a problem that such thing happens during the installation. It happens when you update the dependencies. But concurrent modification in the reactor. Yeah, this is something weird. I understand why it may happen. But whatever happens here is a Jenkins bug. Okay. So I suggest resubmitting a grtk to Jenkins code first. Because yeah, we've been doing something for a task reactor to prevent concurrent modifications. But yeah, then there was a decision that they cannot happen there. Okay. Maybe they can. And then you said that we can keep plugin installation as beta and then just down prioritize or plugin management related issues, right? Yeah. And is anyone objecting? Because I want to release one zero and I'm happy to release it without some features. I'm not happy to release it without features that don't really work. So I'm okay with the plugin management in the first release. It's another question to Nicola. Right. So the main issue here is that we hardly can have unit tests for this feature. So the reason we had bias regressions to happen here. So that's something I can invest some time to test. But I hardly can guarantee that there is no later impacts if we have something else to fix. But we don't have to rush. I honestly think it won't be the end of the world if we have it as it does. We just develop it when we have more time. Crazy conference period. And just added this functionality. Well, as soon as we have it, but without rushing. And then as John commented on the guitar, as soon as the plugin is stable, we should release it in his opinion. I mean, I'm not going to stop you from working on it if you want. But I just want to know if you're okay with down prioritizing. I'm fine with that. I'm pretty sure that we will discover some other bugs in other places. So we know this one might be broken at some point. And we probably will discover there is some other cases in other places on this plugin. So the fact that we release 1.0 doesn't mean it's just perfect. And we won't discover any issue. Okay. And there were some issues with exporting tools installation. Yeah, this specific one is a bit confusing. Because once a cloud plugin has created nodes to absorb load, those nodes are registered on Jenkins. And we can't distinguish with standard nodes. So we will try to export them as legitimate nodes. And in the case of the specific EC2 plugin, there is some blocker for it. But we would have to exclude them. And I don't know yet how we can do. Okay, but when this error happens, does it stop Jenkins? No, no, it just blocks the export. It just blocks the export. Okay. So for me, if it's not breaking Jenkins, I would have it in release 1.0 as it should have maybe. Okay. Unless someone, any of you have a strong opinion about that we should do something else. But I'm just trying to be reasonable. We won't make it perfect. As long as it was mentioned, it's stable enough, I would say we may try to. And then there's another field to export. Yeah, so it generates YAML. There is just an error. Yeah. So this one is for artifactory plugins. And there is some of them comparable ones with just badly designed plugins. So the solution should be on the plugin site. Okay. And then we have, yes, we just have to wait and see. Tool installation fails to load every other restart. That's some strange. That's good. So if I remember correctly, there is a fix for this one. It's the same one. Yeah, exactly. It's already pushed. It's on master. So rather a test, not to the fix itself, right? Test, yeah. There is a fixed part. Okay. Yeah. Okay. So I guess we have to do and I'm okay doing that. I just want to make sure that it's fixed. And the rest of the issues below, we've already been through them because I can see those are the ones that we already had in milestone 1.0. Any of you misses anything before the release 1.0? Maybe it makes sense to review Jenkins Jitter as well. Because some people start reporting in Jenkins Jitter. Of course. Yeah. And I hope that it eventually becomes an official way to report issues. Okay. Remember the link to Jenkins Jitter? Issues. Jenkins. There's ci.org. Okay. There's this very trigger plugin compatibility, but. Yeah. So whatever plugin compatibility is on the blocker for the release. Yeah. It's something really precious. I mean, for me, that's something that should be solved on Garrett's trigger plugin site. Right. Right. So when you see such issues, you can just remove configuration as code component. Okay. There is jcask compatibility label if LinkedIn is needed. So you keep it here, but you remove configuration as code from the components list. And then you can change the assignee. So currently you are assigned to this ticket. Yeah. But you can change it to automatic assignee and then it will be assigned to Garrett to get maintained. Yeah. Automatic. Okay. Okay. Thanks. A proxy authentication work when it's from Jenkins YAML. What is proxy authentication? Plugins proxy. I mean, that's a proxy for update center or. Why would it? Yeah. It's in plugins because effectively it's in a plugin manager. Yeah. So that's something that we can. We want to, there's a stopper for 1.0. Well, it looks important and it looks to be a part of jcask plugin itself. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. And the Next version result. Resolved. Resolved. Yeah. To open. So extension point for marking generated items. Well, it's much more ticket than just the jcask plugin. So effectively, it comes from the read-only WebUI story. then you see which parts are configured by configuration as code and hence not editable and others. So it's not related to Jcast really. It's rather a bigger engine in Jenkins somewhere. And this sector is on global configuration tool. Instance missing single tone. Well, when I see this errors, yeah. It's the most likely Java nine or above. And since there is no response from the report that I suggest just closing it. Okay. So resolve and complete. Okay, L we just closed it. Yeah. 49 and nine are three. Thanks Alec. So yeah, Jira doesn't look that bad. Yeah. So let's go back to the mic stone. As I said, I'm gonna be on vacation. So hopefully it won't be available from next week, upcoming weekends to the next weekends. So the potential release date for me would be Monday eight. Oh, let's do it nine so I can have a time. No, no, no, it's not October, the 19th. So you're talking about one to zero release. Yes. Is it okay to release right before Jenkins vault when everybody will be traveling? I mean, something really wrong goes is one to zero. Yeah, that's why I wanted to do it here and we're traveling like around here. Yeah. I mean, I'm not saying we can't release it earlier. I'm just saying I won't be able to release it this week if we have issues solved. I can probably answer a mail every now and then, but that's it. And I think we really wanted to have it before Jenkins rules. So if we don't introduce something really big, then if we solve the issues, then I don't know, maybe I'm too hopeful, but. No, it should be fine. And the worst case, we're gonna hack it on the weekend before Jenkins vault, don't we? Oh, yeah. Okay, so I'm gonna pretend and I will try to keep my eye on the status every now and then when I have access to the internet and we'll see where we are. Okay, we have some time left. Anything else any of you would like to discuss? Nothing from me. Right, nothing on my side. Oh, no, just not. So for Jenkins world, I've ordered some stickers with the configs called logo, the new one. So for those of us who will join the contributors to meet, both in San Francisco and Nice, you can come back with a nice sticker on your laptop. I just got a new laptop and it's stickers free, so that would be a nice start. Yeah, right. Oh, good, thanks. Yeah. So we were having this meeting every second week and we shifted because last week almost no one was available. So I suggest let's have another meeting two weeks after that one. So it will be like 12th of September unless there is an urgent issue to have a meeting earlier than let's just guitar and see. Yeah, I agree. Maybe it makes sense to add one more item to our agenda just to talk about events related to JCASC. So yeah, there is Jenkins world, of course. Yeah, but you mean to talk about it now? Oh, why not? Yeah, then what else we have, for example, today they will be a Jenkins area meetup in Helsinki. So yeah, there will be a JCASC presentation as well here. And yeah, and actually there is a number of other meetups which present a JCASC now. So it looks like it's pretty popular in the community. Yes, there will be a meetup in Stockholm. I don't know if you have a link somewhere and I will try to find it. Yeah. So I will be probably presenting JCASC in the end of September 11, I guess. Yeah, by the way, there is a full agenda for the day of Jenkins, right? Yes. So the last one we added was a Baptiste about Evergreen. Thanks for pointing out the problem with my bio on the page. So I think we'll try to organize a meetup the day before the day of Jenkins' code in Copenhagen too. It's just not announced yet and fully decided, but it's on my agenda for today to discuss that. Right, so I'm arriving at something like 2 p.m. So I'm available for the meetup if needed. Super nice. Yes, we are considering different formats. So as soon as we have some more clarified idea, I will contact you. Okay. And the meetup will be, so at this meetup before the day of Jenkins' code, well, we don't want to repeat the same material we'll have at the conference the day after and it will be open for anyone, so you don't have to attend the conference. So probably it's not even a code, maybe something else. Yeah, yeah, whatever Jenkins related, just kind of warm up. It's allowed to be a code, of course, but we're not limited. Okay. Yeah. And I think that's all I have. Okay, nothing specific from me as well. So yeah, I just think that the listing events and talking about updates for them would be useful. Yeah, like now you offered to be involved in the meetup, so I find it very useful. That was the idea, thanks. Okay, anything else? Not from me. Into Adon. Yeah, so I guess we can close the meeting. I will stop sharing. Okay, then I stop the broadcast.