 Jenkins configuration is called status call. We have a regular calls every two weeks in order to sync up the current project status and ongoing activities. If you're interested to get more information about the current projects, you can just go to our resources. Just a second, I'll screen share. Okay. So yeah, what you can see that we have Jenkins configuration as code channel where we have discussions and the way we can discuss all topics and we post participants links to the status updates there. So if you want to join, you can just join the channel and participate in the discussions. And regarding status notes, we have a Google doc for all kinds of discussions and meeting notes. So I will put the link to the chat again to the today's meeting notes and we will be updating them during the session. Okay. So yeah, this is what we have for the meeting. And regarding participants, we have Nicola DeLoof on the call, then we have Mars there. My name is Valentin Ashev and we also have Abir Sheikh Gautam who joined us in order to talk about integration between simple pull request job plugin and Jenkins configuration as code. But yeah, I think we should start from common sync up. So yeah, let's just talk what we've achieved over the last two weeks. So Nicola, would you mind if we start from you? Sure. So in the past days, I'm mostly working on stabilizing the plugin in various aspects. So getting feedback from users, get a bit used and trying to fix everything and get things polish so we can have a release candidate. We also have some pending discussion on backward compatibility that will need to be addressed at some point. And most recent additions were to introduce REST and REST API and CLI. So one can push a configuration and check for a configuration. So validate configuration five before it get applied, which probably is something that could help in this backward compatibility issue that sometimes you can just get your config being broken because you updated a plugin or something like that. So that exactly. So some dry run mode that will report, at least report that the configuration is broken. And I'm investigating ways to offer some diagnostic, some automated diagnostic so that GK could be able to say that this attribute is unsupported and should be at this level in the YAML tree because it can detect that this attribute exists somewhere else. That's something that I really would like to see. Not trivial, but let's try. So multi micro status. Okay, thank you, Mars. Yeah, I have been on vacation. So I haven't done much since last office hours meeting. I'm just, I've done a bit of documentation work and they're trying out the getting that the documentation for the plug installation in. So I've just been doing a bit of documentation. I haven't done much work since last. We are looking forward to getting our customers to use this thing. It has a lot of promise. And hopefully with one one to be ironed out the box there are we, it would be, it would be something we can put into production. So that's what I've been doing. Yeah, not much else to add. I looked over the summer of the issues and we probably need to, some of them are kind of hard to understand, to be honest, at least if they need to be done from an outsider. Yeah, but that's what I've been up to. Okay, cool, thank you. So regarding myself, yeah, I didn't go too much during this iteration as well. I was mostly focusing the backward compatibility and other requirements topics. So I was rather creating issues than closing that. Sorry about that. Yeah, I also did a bunch of reviews. Yeah, regarding next steps, we still have a detachment configurator API to separate a plugin. And I think it would be the next thing I will be working on. I'm also working on a recast compatibility page. So as we discussed before, we rather need something in order to demonstrate the current status of support. I've started from a wiki page. Wiki page didn't work well because yeah, actually, I can just show it. Genki CI configuration as code plugin. And so yeah, here I have compatibility, okay. So I've started from a classic wiki page. We had four compatibility issues. So probably you have already seen plugins affected by Jet 200. So just a long, long list of all issues with fixes. So it's a kind of landing page for users who want to understand what they need to update, et cetera. I wanted to create something for JCask, but before doing that, I wanted to automate the process a bit. So instead of that, having some G-requiries or whatever in order to simplify the thing. Yeah, and this is the first result. Embedded G-requiries don't work reliably in our Confluence page. So I worked a bit with Daniel Beck in order to create a new release as field. And yeah, currently I'm trying to introduce a new dashboard for that. Just a second. Okay, so something like that. So far it doesn't look pretty, but yeah, the main advantage that you don't need to do anything except setting one JCask compatibility label. And yeah, obviously I'll try to refactor it to make it better. So yeah, it's what I want to finalize by the end of this week. So we have it for the release candidate. Maybe Viki or maybe some automated thing by G-re, TBD. Cool. Yeah, so unfortunately we don't have Evelina on the call, but yeah, from the list of pull requests, she's working on documentation updates. So there is a big pull request and also we have a counterpart pull request against Jenkins IO. So yeah, I think my focus is to get a documentation and landing pages over the fence. So by the time we have a list candidate, everything is published on the Jenkins website. Actually it's one of the main goals in 1.0 FC. So have I captured everything for Evelina or am I missing something? I think you got it. She's also having it have vacation this week. So, and I remember her talking about things. Okay, thank you. Abhishek, would you like to share something in context of the task? Just in case you're muted. So yeah, probably I could do quick status update for Abhishek. So Abhishek is working on a simple pull request for a job plugin as a part of Google Summer of Code. And one of the tasks for this situation was to introduce configurable steps in YAML. So the main idea of the plugin is to have pipeline multi branching definition as YAML. And in order to do that, we decided to use some bits of jcask and from what I see Abhishek tried this use case and he has already reported few related issues about the plugin. So for example, jcask compatibility in Jira test publisher, et cetera. The use case is pretty specific. It's not exactly system configuration as code right now. It's steps configuration, but I think it's still a kind of useful experiment about compatibility. Because at some point even jcask plugin itself may need such configuration for steps. And yeah, I guess we will have a demo after the one does zero releasing cup. Yeah, thanks Nikola for solving this issue with a number types support. Yeah, I guess it was one which we were missing in the jcask engine. Yeah, probably some small corner case like this one that the API is stable enough so that we can easily introduce such support now. I'm just trying to find a ticket for that. It should be somewhere. Okay, I'll find it later. Okay, so let's talk a bit about 1.0 release candidate. So when we had the first status meeting we have created milestones for final release and for the release candidate. So yeah, let's take a look at the milestone. So one of the things I see that we have or had a plan to release 1.0 received by July 15th. So it's something like in four days. Yeah, so what I wanted to ask you guys is whether it's still a plan or do we need to do some adjustments? If you look at the milestone, right? Yes. There is only, there is four must have issues and we need, we either need to move them out of the milestone or close them before you can do a release. You're working on the compatibility dashboard and you plan to have that done right within the weeks. So that's one down. Mm-hmm. Then there's the issue 277 with the marketing attention points, API is beta. Yeah, I think it's something I could do or maybe Nikola has already done a bit of that. Oh. Yeah, it sounds, it looks simple, but I don't have enough knowledge to know what classes I need to add actually. So I think it's probably something you probably can do in like an hour, right, or something, figure that out. Yeah, probably even less. Yeah. So yeah, self-assigned decision to myself. So yeah, I'll try to do it today. Yeah. Then there's the move several configurators on the side of the Jenkins element. It's not, to be honest, this issue is not really described well enough to be workable. Mm-hmm. Yeah, so one of the issues we hit with that recently, compatibility for global configuration things. So we had the issue with artifact manager S3 plugin. There was global configuration section, but it was moved from one category to another. And the fact that it breaks compatibility with JCASC due to configuration outside the Jenkins element. Oh, it's not a blocker for the release, but yeah, I guess this is a topic which is somewhat related. Nikola has proposed a patch for that. But yeah, the problem that this patch is probably, yeah, so it needs some discussion at least before it gets integrated. Yeah, this one. So the main problem of this patch is that it just skips a category check. So it means that you can apply global configuration to each category independently of a way it's located. It's perfectly fine from the compatibility point of view, but on the other hand, it doesn't allow to have similar symbols in different categories. So it may be an issue. Yeah, a major risk we have to address is collisions between symbols. Oh yeah, we've seen that before. Symbols are supposed to be unique from an API point of view. But if we consider all descriptors on Jenkins, there is a huge risk that we get some collisions at the point. Right, so collisions in symbol names added is designed. So symbols are expected to have collisions. But yeah, the problem that nobody has ever documented when they may collide and the way they shouldn't collide. So yeah, it's a tricky part. To be honest, 110, I don't think it needs to go into the release. That's issue number 110, right? Just a second, I'll open the milestone again. This one. Yeah, so the main problem is that if we do not move configuration now and move it later, it will break compatibility for release candidate users. Okay. So you're not allowed to break accountability in the release candidates? You're allowed to do that, but it may be not that pleasant experience for users. Okay. So for release candidates, we don't have explicit process in Jenkins project. But yeah, I would say that the release candidate implies that something may go wrong there. Okay. So I guess that's why this ticket has been added to the release candidate milestone. Okay. So it gets resolved before we release. Okay. Nikola, are you working on it now or is it a Velina? So I mostly don't on this specific aspect and don't have some pending change for it. So maybe it would be good to have some status update there or maybe we could break down this task and close particular bits so that it becomes clear what is the status. Yeah. Okay. We'll have a look today. And then the last must have issue, right? That's the users should be warned about invalid configuration. But I guess that ties into the rest thing you guys have been working on where you can submit a partial configuration as an API for it and validate the configuration. Yeah, right. Or another way would be to just run dry run mode before running the full mode. So each time somebody submits configuration, we firstly run dry run in order to verify the configuration and if it passes, we run in full mode. Yeah. Yeah, I think that even with dry run we can formally close this ticket. But if dry run happens automatically it could improve the verification flow a lot but in this case it doubles the execution time or maybe not doubles but it will impact the execution time. But it's near instantaneous isn't it anyways now? Maybe that's because I'm working on small YAML file but when I'm using this thing it's like if it took twice as long I wouldn't notice. I think. Well, maybe. Yeah, I also have one of the small configuration files so far so the biggest thing I've ever tried to do is something like 50 generated projects. It worked pretty fast so I cannot grumble but I'm not sure what would be the case for production installations. That's also what's the use case? Is it something people expect? Is it something to do every second or every day or is it something they click every hour or every week? Yeah. Nicholas, can you document that dry run mode? Is that mentioned anywhere in the API? I didn't know that we had it. Yeah, as part of the API you know I have a check method. Okay, okay. It's explicit and you also have check REST API and check configuration CLI. Oh, okay, so that's the... The actual implementation is based at the lower level as the implementation is based on running the configuration with a dry run flag so that we don't actually apply the resulting configuration. Okay. As this is only used to avoid code replication but at the higher level you have two explicit methods. Okay, okay. And it's documented so people can use it if they desire, right? Depends what you mean by documenting. It's defined in the top level API. Yeah, okay, good. It's mentioned somewhere in the README that you can do dry run. Okay, good. I haven't checked in a while. Good. Mm-hmm. Oh yeah, I just raised a question to Buu to understand what he expects to be there. Yeah, I just said it's my proposal. Mm-hmm, yeah. If somebody wants to implement that it could improve the behavior a bit because you wouldn't need special flags. Yeah, I can take a chat with Buu this week. I can make sure that we close that thing. But that would be nice. Okay, it would be great. So yeah, it's just for prior one releases in addition to that in this experiment we have. Yeah, what do we have? Okay, this may be an HP error. I didn't resolve it so far and I think it's something I need to do. But the main problem that it causes it may require patches in CISPOS library and I'm not 100% sure how to do them. So maybe I will just refactor the extension point I've created in order to avoid this issue with class loading. Okay. Yeah, it's just specific to the General Peel Launcher class because the General Peel Launcher class loads Jenkins class and then Jenkins class loads lots of the things including all kinds of admin callables, et cetera. So it becomes a really, really big entity to be loaded. Yeah, probably I will just refactor the logic somehow. So everything comes from here. Everything actually comes from here. I'm using this bit in order to ensure that the extension is optional. Yeah. But yeah, technically I can just remove optional flag, hide this class and then it will be loaded correctly. So it's something TBD. Okay. Okay, what else? Getting started documentation, working progress by Wilina? Yeah, I can ask her. And the state of that thing? Yeah, maybe she will follow up after the call and create the AgCasks sub-project. It's definitely working progress as well. Yeah. So it's Jenkins. Yeah, so actually it seems we're doing good. Yeah, it looks good. But maybe because I see that at least three of the four can be closed within the week, right? Yeah, right. The only one I see that it might be blogging is the 110. There's configurators outside of Jenkins element. Yeah, but I think that Nicola already did a lot of work here. So yeah, maybe we just need to understand what still needs to be done. Yeah. So, are we missing any other stories in the release candidate? I think it's good. One thing I noticed is that we actually did more like the campaign approach. A couple of issues got injected with the Inom thing and the Maven installer things also got added. So we've put in more work in the release candidate than we actually planned. Yeah, right. So that's good. Yeah, that's right. So guys, if you want to have something to be added to the scope, just add it to the milestone. So it was quite opinionated at least. We created the first meeting with Evelina in June. So yeah, the plan may have changed since that. So if you see any other issues to be resolved for the release candidate and probably more important for the final release, just add them to the milestones. Yeah. Is the schedule very important because we've scheduled it to be released on the 15th? Do you guys think that you have time to solve all the must-haves before that date? I guess it's rather... So for my tickets, this one I believe I can do. This one I believe I can do. This one, if I do not do that, it's not a problem because the API is restricted anyway. Yeah, and also not prior to one. So it strictly doesn't need to go into the release. Yeah, cool. Yeah. So, but I don't know about the rest of them, but is this how do we believe we can really do a release candidate before the 15th? So... Yeah, I would rather prefer to be on the safe side and say July 18th. So we have a week, but I'm not sure what is the schedule and what is the demand on your side. I have had... The only thing we talked about was the Jenkins world and the events coming up, and we just wanted to have something in the official updates before that date. Oh yeah, so we have plenty of time. So I'm okay with moving in three days if you need, you can solve most of the issues by then. Yeah, I guess it's another question to Evelina. So personally I don't have a strong preference regarding the release date. I'm perfectly fine with alpha releases. Yeah, me too. But we can ask Evelina what she prefers. Yeah. Do you have anything to say to Nicolas about this? No preference on my side. Okay. I'm perfectly fine with alpha releases. Yeah. So I guess we just try to close these things up and then we'll see when we ship. Because yeah, I think the main thing for release candidate is rather promotion. I'm not sure whether we really need it or not, but generally having Jenkins IO announcement like a blog post is something we could benefit from when all these compatibility pages are ready so that we can start processing the feedback from the field and addressing that. Yeah. Because one of the major issues we have ahead is plug-in compatibility. Because yeah, even now we just, so we have created a label. We already have something like 12 tickets there. Yeah, but they are mostly related to JCask itself. Yeah, I think that we will hit more plugins which need to be updated. So we have Locale plugin. It has been already updated a bit. It's a ownership plugin. Artifact manager is three reported by TIST for the Jenkins Essentials project. Then we have remote in Kafka and JSOC which also needs patches. And the EC2 plugin also reported by TIST. So Jenkins Essentials team is already adopting configuration as code plugin. And I guess we will have more feedback from them. Yeah. This is some of the things that I might be able to submit pull requests for. Can you put the link in the message box on the filter you created? Sorry, what do you mean? The tier issue filter. Can you put that in the Google Hangout chat? Oh, yeah, sure. Yeah. I just need to find the Hangout chat. Okay. Cool. So I think that if you see or if you know about other compatibility issues, I think it already makes sense to start reporting these tickets. Yeah. So that it will start filling in other content. And yeah, my action item is to actually get this page somehow published. Yeah. And that's just put it on the Viki, the readme.md file for now. Yeah. That's the plan. Yeah. Yeah, it would be much easier if JIRA queries worked in Viki, but they don't. Oh, wow. Yeah. So I will try to embed the dashboard here. That's why I've started creating a dashboard in Jenkins JIRA. Okay. Okay. So that's the compatibility. So likely I will start from just putting it there. Which, yeah, probably it's not a 100% approach because yeah, we still have plugins which do not use JIRA as the main bug tracker. So for example, Docker plugin mainly uses GitHub issues. And yeah, there are other such plugins. So likely we will need to still add some flexibility. But I wanted to avoid the case we had for JEP 200 when all these things were monolid. Because it consumes a lot of time for my containers. Yeah. Okay. So yeah, I guess that's it. So we move the, let's see, maybe inside it. Okay, so something like that. Yeah. Okay. So simple pull request job planning. I think we could spend some time and let Abhishek present his project and then go on integrations because it may be interesting for participants. So Abhishek, are you ready? Yes. Okay. So yeah, then the floor is yours. And thanks for your time. And thanks for joining the meeting. Okay. So I will share my screen. Yeah, if you prefer. Yeah. Can you see my screen? Yes, we can. Yeah. Yeah. In this one, how I integrated Jcast plugin into my plugin. And I'm using Jcast plugin to create step objects so that I can use a snippetizer dot object to movie function to create a snippet for a step. Maybe it would make sense to start from examples of YAML definitions. And yeah, you could briefly explain what the goal, what is the goal of the project because not everybody actively participates in Google Summer of Code. Okay. So yeah, we have a format for Jenkins style of YAML in which we have stages property. And then in that we will have a array of stages. And then in that we have steps, steps array, which will be defined like this. This will be the name of the step. And then the parameters. So what I wanted was that to take the information of steps and then somehow convert it to pipeline snippet so that we can use these steps in the pipeline. So yeah. So for that I have a step contributor function here and I am passing a step object that will be defined in the YAML file and it will be converted to Java object. So in here what I am doing is if a step, if user provide only one parameter, then it will be a default parameter and I am using configurator.getData1 constructor and I am passing the class of that step so that I will get a constructor. And then I am just using constructor.newInstance to create object for that step. And then I will call snippet.tizer.objectToGroovy function to create a snippet for that step. But if users will give more object, more parameters for a single step, then I have three functions, which are do mapping for map, do mapping for scalar and do mapping for sequence. So what I found was if we need to create an object, we need to pass a mapping object, a C node object in configurator.config function. So I am building a mapping object through the parameters from the parameters that I will get from the YAML file. So these three functions, do mapping for scalar, do mapping for sequence and do mapping for map are doing that only. And then I am just using, I will get a configurator from configurator.lookup and I will pass the class of the object, then I will get configurator and I will call the configurator.config and pass the mapping object. So that I will get a step object. And then again, I will use snippetizer.object to groovy to get the snippet of that step. And I will place it in the pipeline snippet code appropriately. Yeah, so this is how I am using jcast plugin for this, to generate snippets for steps. So effectively it's a universal engine which allows to create, to convert YAML definitions to pipeline code. Yes. Looks really good. And what is your experience so far about this engine? Yes. And as already mentioned, I got some problems with NM classes and the configurator.lookup method was returning null for a Java utl.concurrent time units class, that is a NM class. And yeah, I have created an issue for that also. And I think it's been fixed by Nicholas in PR. And one more issue I got. Yeah, it was to configure Gira Test Data Publisher class in that there is some environment. It gives null point of exception for a REST client. Yeah, so Nicholas said that many others and Gira Test Publisher descriptor are using manual data and data binding code. So yeah, this is the problem I am facing and it may be the case with other parameters and steps also. Yeah, it's a problem for many old plugins. So I mean Hudson course maybe before 1.200 or so didn't have data binding APIs. So plugin developers were implementing processing of JSON objects on their own. Yeah, it has changed years ago but we still have this code in some plugins. Yeah, I guess it's not a problem for your project, but yeah, for JCASC project. It's likely a problem when the same happens in system configurations. So for example, we had matrix authorization plugin or all strategy plugin which had similar issues. And yeah, I guess our response is to create custom configurators for that or to just update the plugins to new APIs so that JCASC starts supporting them automatically. So what do you think guys? I prefer to fix it in the plugin. Many of these plugins could use an update with the new idioms about data binding. I don't know, is there a generic use case or some method that can be used on every single of these cases to fix compatibility issues? Well, there is no silver bullet as always. In some cases of course we could convert YAML to JSON and then he'll fit this JSON to the plugin descriptor in new instance and to see what happens. Yeah, I guess Nikola was against such approach and I would rather second that because this approach is extremely risky. You never know what's going to happen because descriptors are quite obsolete, they may be checking permissions, they may be accessing runtime and if you wrote YAMLs to JSON forums and then to configuration it's not clear what's going to happen after that. That's true. Okay, back to a simple pull request of a plugin. So what do you think about such kinds of integrations? Is it something you considered when you started working on the plugin and is it something useful from your point of view? From my point of view I need to know more. For the simple pull request of plugins how are you using this YAML? Is it something you're putting into the configuration of the plugin or are you... Can you show us an example of how this ties into JCask? How it's working? I'm not sure what problem you're solving at the moment. Maybe it makes sense to just show an example. Repository? Yeah. Actually, you can show what you prefer to answer this question. Okay. Yeah. So the main aim of this plugin is to define the job or a pipeline by YAML. So what I'm doing for that is I have all these things and define these things and define here classes for all of these things here and when I parse this YAML I will get all the configuration in this class YAML pipeline. So in that I have one thing that will be inside the stages class and now I need to convert this step object. This can be anything echo shell or something. I need to convert this step object to a suitable pipeline code that will be able to run the steps. Yeah. From a user perspective the idea that you have a repository currently you can define Jenkins file which is a definition for pipeline which can be used in multiple branch to create automatic SCI, CDE for your branches and the idea was to have something like that for YAML definitions. So it's a kind of holy bar some people like YAML or other modeling languages people just prefer programming languages and the idea of this plugin was to offer a YAML engine which allows configuring jobs easily. So that's what has been created and before that there were several reference implementations for example Nikola has created a code chip plugin and there are other YAML based plugins this is an implementation which also introduces such multi-branch definition but as YAML and YAML gets converted to declarative pipeline now. Okay, but one question where is this YAML stored? Is it something you configure in the symbol pull request the plugin? So YAML is stored in SCM. Okay. And then you just point to the okay, but okay. Yeah, the YAML file will be stored in the repository itself and the plugin will pull fetch the YAML file and then create the declarative pipeline pool. Okay, okay. So yes. So like you can see here we have stage one and we have these steps a shell step, sleep step and JM step so when I build it this pipeline code has been converted. Yeah, okay. And stage one and these are the five steps. Okay. Yeah. Okay, okay. That makes more sense. You're just taking the the GUI pipeline and made into YAML and then you get out GUI pipeline and you can use the the JCAS configurator to configure all this stuff and convert to GUI. Yeah, right. So the idea that the plugin will have its own extensibility engine but using JCASC looks like a good option to support the white number of steps out of the box. Yeah. What I especially like about this approach and that it gives combination of JCASC and pipeline snippet generator so that we integrate two tools together in order to convert YAMLs to pipeline. Mm-hmm. It looks pretty promising as an approach so far. So Abhishek, how many plugins have you tried so far? I have not tried so many plugins. Actually, yeah, I have this used to where it is. JUnit plugin and in that we have this Jira test publisher parameter. So for that I choose to I don't know Jira test reporter plugin I think for this step we need that. Yeah. And also sleep step from what I see in comments. Probably I didn't hear you. So in the top you also have sleep step and according to comment it's also implemented by JCASC. Yes, yes. Mm-hmm. Yes, this is a basic step in the pipeline. Yeah, so in that I was having difficulty with unit parameter and yeah, for this Nikolas has created a public request and it's been merged. So in next release it will be fixed. Yeah. Yeah, by the way it may be an interesting question to discuss. Maybe it makes sense to ship another alpha release. You saw the current changes in the master because yeah, CLI is there, REST API is there, then it's an unconfigurator. It looks reasonable to ship another release. I'm fine with that, yeah. Nikola? But it's just for you guys it's just a matter of pushing the bottom right and do it nice. Okay, if it's just pushing the button, yeah, maybe it makes sense. Yeah, it would be cool. Yeah. Yeah, let's see what else we can learn today. I will try to create public request with accessibility patches in a few minutes. No. No? Okay. Thanks, Max. So unfortunately we don't have Evelina on the call, but yeah, she said she's going to watch the recording. So maybe we'll get more feedback. Yeah. Nikola, are you online? I see Nikola on the call, but yeah. It's Avatar. Yeah, right. Anyway, we can follow up later. Personally, I think that this approach is helpful. If it flies well, one of the things we could consider for simple pull request job plugin is to offer configurator for steps. So currently, JCASC plugin uses it uses JobBSL to generate jobs. But one of the possible options would be to have another configurator powered by JCA by simple pull request job plugin. So it would be also possible to define simple jobs as YAML directly in Jenkins YAML or maybe in other included plugins. So it would be also a nice integration use case. Yeah. Yeah. Yes, that would be great. Yeah. I'm not sure we will get to that because JCASC is a limited time project if you have something like four weeks of coding left. Let's see. Yeah. Cool. I think that's enough for me for this meeting. I learned a bit. It's an interesting concept and I can definitely see this could be useful for replacing the Genesis jobs with jobs that we have. Yeah. Cool. It's probably not replacing because job design is much more flexible because it's job design. Yeah. For simple declarative syntax it's something which could be viable because defining multi-branch pipelines in JCASC is problematic. For example, recently we had an issue with retriggering of old builds because there was no job IDs or something like that retained in the guidelines. So there was a patch to the documentation but maybe having a specialized engine would be useful. Just a second, I will find this patch. It has been submitted a few days ago. So it's pull request number 344 from Stefan Miller. I've pasted the link to the Gitter chat. Yeah. So it's probably one of the examples when we need to be careful with JCASC logic. Yeah. So maybe I'll be sure it's something for you to consider. I'm not sure how the plugin handles it right now but it may be a case for a simple pull request job. So if you open up file changes you may see that it's just actually adding ID. So ID is not generated by default. Mm-hmm. That looks so. Okay. So for simple pull request job plugin it may make sense to create a follow-up task and if it's not added by default maybe it makes sense to it in the plugin. Okay, yeah, sure. Okay. So yeah, thanks for your presentation and if somebody is interested tomorrow we will have Jenkins Online meetup about Google Summer of Code and Abyshek will be doing a full demo of the project. So if somebody has any feedback or questions please feel free to join this meeting and we will talk more about the current status and then probably JCASC integrations as well. Yeah, cool. Oleg can you put the link for that presentation in the gondila? Yeah, sure. Because I might be able to in a second I will also put it to the chat. Yeah. Okay. So yeah, I guess that's it for today. So do we have any other topics to discuss? Not on my end. I got what I wanted to. Mm-hmm. Not from my side. So I guess that's it for today then. So thanks to everybody for speaking or for watching the status update. Join us in two weeks. Hopefully we will have a release candidate by this time. So we will be much more open in terms of plugin integration feedbacks. And even now if you try Alpha version if you see something please report issues and we will try to take a look. Okay. Thanks again and see you soon. I'm stopping the broadcast.