 Okay, now we are recording. Hi everyone, today is November 13th. We have a non-regular Jenkins Contributational Score project meeting. Usually we meet every two weeks, but this time we decided to have out of order meeting in order to make presentation of Jenkins Contributational Score project by Sliden. Sliden is a community bridge mentee. He started working on G-Cast developer tools in almost and yet he will present his work. So yeah, the agenda for the today's call is just to have this presentation to discuss the results. And if you have some time left after that, we can discuss common project matters. We have several people on the call. So it's Sliden, Keem, we also have Antonio and John. And yeah, I think we can just start if anyone wants to do meeting notes, we have a common Google doc for that. So yeah, you can just find it in G-Cast project references. Okay, should we begin? Yep. Okay, so the floor is yours. Yeah, thank you so much. Okay, so hello everyone. So I am the community bridge mentee from, okay, hold on a second, just let me share my screen before I start. Sorry for that. Yep, so I'll go on talking by the time I share my screen. Yep, so I'm the community bridge intern from Jenkins. I started working, I think around in August. I think three months before. So my project was dealing with the G-Cast validation, the schema validation and developing a plugin making it much easier for the developers of the G-Cast in general to just be able to configure their YAML files. So that's whenever they, I mean, you wanna set up Jenkins, you wanna set up a Jenkins project using the G-Cast file. There wasn't any provision for editing or being able to make changes to the, I mean, being able to have any feedback while writing. So you could have errors creeping or you could probably make mistakes and then you could just apply the configuration and realize that it's not getting applied. So what we decided was to be able to, I mean, rectify that. Yeah, it's not in the screen share and because I'm working so far. Yep, yep, I will share. Okay, so yeah, if it's intentional, sorry for interrupting. No problem at all. So yeah, okay. So I had my mentor, Tim, who was very, very helpful and supportive throughout the project. So shout out to him. Okay, so what was the project about? Yeah, so the main idea of the project was to enable developers to validate the YAML files that they write for Jenkins instance via G-Cast. So we thought to make life easier for the users by developing a VS Code plugin. I mean, the VS Code plugin is just writing, it comes as a hand-in-hand along with the validation which is the major part so that it just pulls in the schema file for the Jenkins instance you're running. So I'll just, I mean, I'll just explain to you how we plan to do the project initially. So initially what we decided was the initial schema was written in jelly and which made it very, very difficult to test. So what we decided was to be able, we needed a better testing framework for the schema so that, I mean, we could test it much easier because it was a pain when it was written in jelly. Okay, so what we decided that we would split it up in two phases. Phase one would deal with the schema redesign and phase two would deal with the plugin development. So initially, we set on supporting a set of different plugins like IntelliJ, I mean, set of IDs, I'm sorry, such as IntelliJ VS Code and so on. But we decided, I mean, your time constraints and it being, it took a lot, lot of time to actually redesign the schema. So we went with just supporting one single IDE that being VS Code because most of us, I mean, it's a little by everyone. Okay, so let me just talk about phase one since I'm doing an entire project overview. I'll start with the schema redesign. So the things that we did in this, I don't want to go too much into technical details because this is being a demo and it will make much sense to the users that if I just go on to the meet. So one of the things that we did was we wrote the entire schema in Java which would make it much easier to test. And I mean, in case there were any modifications or any further API schema that we want to develop on top of this, it would make it much easier. So some of the advantages of doing that were to be, like the schema can be tested with the highest average for the generation functions and it would be easy to modify and restructure if necessary or if there is any, if you want to develop any API on top of it, so that makes it much, much easier to do. Okay, so one of the things that we, I'll come to the disadvantages later. So I could just, just hold on a second. So I think if I just go through the presentation before I begin with phase, it would make it much easier to understand. Yeah, yeah. So once we redesigned the schema, I mean made it much, much better to use, we decided to go in with a VS Code plugin. Now what the plugin does is essentially, what you have to do manually is to initially insert the schema and then write your Jenkins YAML file and then just use the schema for validation. Using the Red Hat plugin, which was developed, I mean the YAML plugin was developed by Red Hat. I'll come to the details later, don't worry about that. So basically what we decided was, we wanted to make life much easier for, even much easier for developer so that they don't have to go in and pull your Jenkins. I mean, if you go and look, you can see this screen. I think it was on the side. If you have a look at the Jenkins, configuration as code. So what users had to do initially, so this is the newly generated schema. What users had to do initially was, we had to just copy this entire schema onto of JSON.schema.json file and then use the Red Hat plugin to validate. So we decided that isn't very efficient for the users because then they'll have to just keep downloading the schema again and again and again. So if there is any change made whatsoever, if there is any new plugin installed or there's new security changes or whatever. So what we decided was to be able to make life easier by installing the, by developing a VS Code plugin. So what the VS Code plugin essentially does is, it does all of this for, it takes in the latest changes from the Jenkins, from the Jenkins instance and then downloads the schema file. So what you basically as a user have to do is just, just write in your YAML file, make some settings changes and then you're good to go, which I will show you, okay. So move ahead. Yeah, so what does the VS Code plugin do exactly? So the VS Code plugin basically just downloads your instance by using your username and token, which ensures that we maintain complete security and there is no half-hearted attempt in ensuring that there is the user's own, I mean, the admin of Jenkins, who's running the instance is fully secured. So what we decided that the VS plugin ensures that you don't have to go in search for the latest configuration. So that's another plus point because you don't have to manually go in and navigate using a bunch of UI buttons to the Jenkins, to the schema file, download the schema file, copy paste it in the file and then do all of that. You don't have to do that. You just give us the URL of your Jenkins and your token and move, we run in with the instance. If you want, there is, if you can find the plugin here on the marketplace, so these slides will be shared with you later. So you can just have a look at up if you want the marketplace URL that we shared with you. Another point that I wanted to touch on is if you want to read more about, I've not gone into much detail about how we implemented the phase one, the configuration, but if you, the schema, I'm sorry, but if you want a rough overview, I could give it that we, in the schema redesigning, basically we just took the old schema that had been written in jelly and there was not a hardcore conversion that we did, but basically we made sure that for every, for every key value pair that we generate, there is a corresponding descriptor and no descriptors were missed out and basically it's just a redesign with a few modifications actually. If you want to read more about it, I have a blog post, so for the slides shared with you, you can just read the blog post that is quite informative and descriptive, so you can just go on and have a look. Okay, I think that's about it. If you want, that's a word for my presentation, of course, the demo incoming, you can go and read much about, you can have the plugin URL, the meeting URL, you can just hop onto our guitar and kind of comment over there. Any feedback would be very, very highly appreciated. So, okay, so hopping on to the demo. So, let us begin. So, basically the first thing that you want to do is obviously have your Jenkins instance running. So, that's, yes, I don't need, hold on, yeah. Sorry, Jenkins instance running. So, if you see here and configuration as code, you have the JSON schema URL, so you can, if you want to manually anytime, check out the schema, how it, I mean, what are the contents, you can easily go ahead and check it out. So, step one. So, step one is to navigate to your favorite ID. Currently, we support only VS code. So, I mean, we have plans for IDs for everyone, yeah. So, okay. So, step one would be to fetch our, fetch our plugin, I think it is, take care. Yeah. So, apologies for the user docs because there haven't been much written, but you will get a detailed user doc. I mean, how to use the schema, how to use the plugin essentially written here. So, you don't need to worry about that. So, once you install the plugin, you just, in this plugin, I think Joseph just added a fix so that you don't have to download the Red Hat plugin, but yeah. Once you download this plugin, you need to make sure that you have the Red Hat YAML plugin installed as well. So, that is this one right here. So, because our plugin essentially depends on the auto completion and the entirely sense on the Red Hat YAML support, because they have the language server well implemented and it's no point in reinventing the wheel. So, we start with the YAML, the Red Hat plugin that was developed. So, once you have both of these plugins all set and ready, what we need is, okay. So, first of all, your Jenkins instance, log into your Jenkins instance, obviously, and so, once you're logged in, you will be able to generate a user token. We need this user token to be able to maintain complete security. So, if you see here, I mean, you can generate your token here and you can name and give it a username and you will get the token generated. So, what you basically do after that is to go to File, Preferences, Settings, and just search for JGASC, because that's okay. So, you enter the schema URL, that is the URL from your browser and you enter the user token. So, I've generated a user token, as you can see. The username is said and I did and you will get your user token. So, after that, what you do is you basically don't, you activate your plugin by using controls your fee. And if you have a look, you can see it right at the top but if you don't find it, you can just type in Jenkins and it'll order completed for you. And you hit the first, you obviously click it. Once you click it, what the plugin does is it downloads a JGASC schema.json for you in your current working directory. So, if you wanted to download it elsewhere, I mean, you could just open the editor in your directory and just download the schema, the JSON schema. So, as you can see, this is the schema that we've downloaded and it is named as JGASC schema.json. You can rename it if you want. So, ideally, I would suggest to keep it as it is. Making it much easier for you to know what the schema pertains to. After that, you just have to configure a couple of settings. Now, why you need to configure these settings is because we need to tell the Red Hat YAML plugin that, hey, this is my schema file and I want all files with YML to be auto-computed using the JGASC schema.json. You can definitely modify this reject as you wish. There are a couple of modifications mentioned in the blog post. You can go ahead and check them out. So, what you would essentially do is to ensure that this name and the name for your schema is the same because this is essentially your key. So, you rename it to whatever you've renamed the JSON schema to. I would recommend keeping it the same or you could keep something shorter if you're not fond of typing like me. So, once you do that, you can essentially go ahead and create your, I mean, this is my user space you don't need to. You can just go ahead and create a new Jenkins.yml file. And once you create a YML file, I think that's basically it because now you have your Red Hat plugin installed, you have the VS Code plugin installed, you have your schema and all that is left is, I mean, to go ahead and complete, I mean, let's go ahead and write down your file. So, for this demo, so as you can see, if you go ahead and want to configure a basic Jenkins, for example, you want Jenkins as a root configurator. So, as you can see, IntelliSense is well supported. If you, I mean, I guess in the initial schema, we had JDK supported as well. This one. Yep. I think it was Jenkins. It's quite short. Configuration is... Hold on a second. It looks like a demo effect. Yes. So, yeah, as you can see, if you just go ahead and, I mean, type out whatever you, I mean, the system message or something, IntelliJ will just complete it for you because you already have the JSON schema. Along with that, we have the validation. So, if at all it recognizes that you're typing something wrong, you would get it highlighted because the Red Hat plugin supports that as well. I guess I could demo it if it was showing me something. So, hold on a second. I could... There might be something, because it's wrong for the settings. No, hold on. I have to crash. Check out the schema to JSON that I wrote. Hold on. I'm not doing it. It will pull the file from me. Create a file from me. Change it to a file from me. Good boy. Yeah. So, hopefully this takes, but it doesn't stick at all. Yes. So, if it was sticking, it would obviously highlight all of the changes that you made, and it would tell you that it expects an object instead of a value key, value pair. So, you would essentially realize that the plugin validates itself. So, that would be basically it for you. And then you can easily, with one of the features that we planned to do was once you apply the configuration, it would automatically validate it. So, you would go through the pane of validation, you would just use it for our completion, and you could, I mean, just load it into jcasc and that would work right out of the box. Yeah, that's about it for everything that I wanted to demo. If you have any questions, you can just throw it at me. There was one issue created by Dominic Bartoldi about multiple visual studio code plugins for Jenkins. The suggestion was to move our identification project to a separate plugin, I guess. Have you considered for that while working on this plugin? No, actually, we haven't considered that because the authentication part was suggested by him so that if the user didn't have any permissions, it wouldn't make it much more secure to have them. But as he suggested, I mean, that could be possibly one of the things that we would consider making a VS Code plugin for authentication in general, so that we can support, because every time the user would have to configure it as you can see here itself, you would just have to change a bunch of settings so that maybe as a future project or maybe as a continuation of this as well, you could make it much easier for users so that they could just write a single configuration and that would, I mean, the plugin would take care of the rest. It would be pretty if it was automatically discovered and Cajun can see on our piece. He doesn't cover all cases, but at least basic ones. Yeah, right now it doesn't seem to work even for that. Maybe 80 years old could help, I'm not sure. Yeah, I think it's working, but I think the schema, that's an old schema or not a right schema that was done like that. Yeah, because if you've, I mean, if it's working, if it's picked up from the old Jenkins instance, you would not get any, we don't get any, the schema would just not, it's not just not correct for the other one. Yeah, so we have some time, maybe we could try to get real schema. Yeah, we could actually. Hold on a second. So what version of the configuration's code plugin are you using? I think we picked it, I think 138.4 to, yeah, it was 138.4. So yeah, as you can see there isn't, yeah, there isn't the things that we initially planned in the schema so, because I can't find Jenkins, you can find, you might be able to find Jenkins here. So the autocompletion doesn't work with that version because the nested configurators PR was never merged. Yeah. So only type validation works with the current version on master. Do you want me to change the branch? So I think you would get your type validation if you put Jenkins system message and then a number in there. Yeah, what's the system? And the space between the two. Yeah. So the type validation's working, but if you could swap to the branch, that's not merged. And if you could get the schema from that, then that would look a lot better. Yeah. Yeah, so what do you want me to do? Oh, sorry. Yeah, go ahead, go ahead. Yeah, so it means that we still need to do some integrations and releases before this functionality or fully- Yeah, yeah, before it, actually we have tested it on the nested Pima and it does work pretty, it's pretty cool. But if you have that PR modes, I think that would help us a lot with the nested Pima because that's the entire crux of that thing. Yeah, so that PR works pretty well. There's a couple of bugs which need to be fixed, but could be fixed in follow-ups potentially. Yeah. I have a question. Yeah. Yeah, so to begin with, thanks for this work. It is amazing. I think it's going to be really useful. And my question is, well, it's more a thought, but in an enterprise context, you usually have to manage more than one Jenkins instance. Have you thought about somehow integrating the schema URL into the Jenkins Jamel? So everything you need is inside the Jenkins Jamel already, other than the username and password. That could be IDE setting, but then the Jenkins Jamel could point to the actual schema URL of the Jenkins that that Jenkins Jamel is for. So you can handle multiple Jenkins Jamels in the same IDE without having to change the URL to Jenkins in the settings. I don't know if I, if I raise an issue on GitHub, sounds like a good feature request. Yeah. No, I'm not, I'm not sure how you'd handle it, how you'd know which Jenkins, I guess you could do it by the file name and configure a mapping. But yeah, it sounds like a good feature because you may have different Jenkins with a different plugin to the scheme as well to be different. Yeah. So one of opportunities is to extend the Jenkins Jamel schema itself to inject this metadata. Because yeah, we already have GCAS coding self-configuration in Jenkins Jamel. So nothing really blocks us from injecting extra data there. Yeah. I'm not sure if it works so well because you can merge multiple schemings together so you can have like your security, your common and your instance-specific Jamel files and they'll all get merged together. Yeah. But possibly it could go there. Yeah, technically we could say that there should be always Jenkins Jamel master file which includes this basic configuration and metadata. So yeah, it's a subject for specification improvements but we can probably do such a change. Yeah. So yeah, I have a general question about this work. What's next for the plugin? Yeah, we see that there still needs to be finished. So what's your plan for that? Yeah. So the first plan was to actually get the nested. Actually, I was going to get the nested scheme of merge I didn't account for my confidence appearance. Actually, I wasn't sure there were others going. So I'm sorry for that. But during that time, I guess the next part of the project that I had planned was to fix the nested schema because that is the entire PR that probably will let us work with almost all of the descriptors as you can see here. We don't have some, we do have Jenkins but we don't have the nested support for Jenkins. So that would be one of the first URLs that serve first PRs to get merged. And I think apart from that is, I think there was an issue on GitHub created for having a, I think sort of a generalized plugin. So that's probably a second thought of consideration. Yeah, those probably improving the plugin to an extent where it's usable not only for Jcast, I think across the board would be, I mean, a plan. Yeah, that's a lot of it. That was me. Thank you. Yeah, are there any other questions or comments? Maybe you would like to add some comments about the project, about the status, et cetera. Yeah. So I think that from a much better shape than what we were before, previously did the feature for the configuration as code schema, just unfortunately didn't work at all. So we've had to throw that code out and we now have a much easier to, well, the code's a lot easier to follow, there's tests around it and it's much easier to extend and fix bugs around it on a case-by-case basis before it was some pretty crazy jelly code that not very many people could understand. And so even just out of the box, most plugins just work. Once we've got this nested, this nested, the progress that's outstanding merged, then this should work a lot better and it works really well. There's health documentation in line in VS Code for all the properties. You have auto-completion, everything you want, all your intelligence. And the VS Code plugin doesn't do a lot at the moment, but it does make it easy to fetch the schema and update it without having to go into the Jenkins UI, so it's quite useful. But it's a good starting point for further extensions as well and any ideas are greatly welcomed. I think the links to the GitHub's have already been sent out, but just feel free to raise any issues on GitHub or come join us and get in and send any feedback along. Thank you. So yeah, I would like to add that it was basically our first community bridge project. So yeah, community bridge is a new project produced by Linux Foundation just last spring. And our idea was to try out some project ideas which we can self-fund as Jenkins project. So basically we're using Jenkins funds for this particular run and we will be doing community bridge projects again next year. So yeah, thanks a lot to Slade and to team for running it because yeah, I know that it was a bumpy road because we just started, we still need to document something. It's not like JSOC, which has probably too much documentation for everything, but yeah, we will definitely improve and anything that will be welcome. But from what I see that yeah, we actually were able to get some good outcome. Yeah, it needs to be polished. It needs to be integrated, but the major things are integrated and hopefully it will be useful for Jenkins integration as both plugin users. Okay, are there any other comments, questions, topics? Slade and did you get the, were you working on getting your PR setup instead to show you that one? Which the nested schema? Yeah, I thought you were. No, no, actually, I haven't got that ready to you. I mean, if you're developing the plugin, we could just hold another demo and get that working out. I mean, if you have the nested schema done, we could just hold another demo for it. It's not like I'm abandoning the plugin. Yeah, so what we could do, we could schedule, for example, Jenkins online meetup to talk about Jenkins integration as code. I'm not sure what would be the timing. Maybe before Jenkins work, maybe after. So for example, if we could get two talks related to Jenkins configuration as code, I'm happy to organize an online meetup for that. Yeah, that sounds good. Mm-hmm. So, is it working? So, Slade, what do you think about two weeks? Would it be enough to just close down this stuff? Yeah, I guess it would. Yeah, I do have my exams coming up, but I guess if I, I'm not sure whether I'll be able to commit to contributing within this period, but I mean, if at all I do get, because it's from the 14th to the 26th, so I'm busy for around two weeks, exactly. But I'm not sure whether I'll be able to commit, but if I do have time, I will. So, but I can't make any promise with this to the next two weeks at least. Maybe after the 26th. Yeah, let's take a look. So, yeah, this is our calendar. So we have Jenkins online meetup on Tuesday at this. Next week, we have another one on Friday for documentation still needs to be announced. Yeah, then one week, yeah, so this is Jenkins for. So after December nine, we can basically take this week for this week. Yeah, December, yeah, December nine, 10 sounds. Okay, then I'll just start the doodle. So if all of us agree that we do online meetup, I'll see what we can do for the second topic, because yeah, it's better to have two presenters. Oh, but we can do just one, or maybe overall overview of jcascadvancements over past year, because we haven't done that yet. So yeah, okay, in December then. Yeah, that's something. Okay, so yeah, I think we have enough time for that. Okay, so yeah, thanks a lot for that. Should we go back to the common agenda, or should we just close down the call because I'm not sure how much time everybody has here. I need to go, and my battery's got like five to six. Okay, so I think that, yeah, so we are back to the common schedule, I guess, so we can do the meeting next Wednesday during the usual time. Are we able to adjust it an hour for, they like saving? Oh, that's a good topic. Yeah, so okay, I'll adjust the screen again. Do you see it? Yeah. Yep. Yeah, next to JPCasc. So yeah, the scheduling meetings would be nice, maybe even moving them to the timeframe when United States can participate, but yeah, I'm not sure. Yeah, I can move it later as well. Okay. So I can just start to do the, for example, I'm not sure how much slots I would have for that, but yeah, let's try to find something. But yeah, it would be important to keep running jcast meetings. Maybe if you can drive attendance a bit so that we get mostly call us participating. Um, yeah, we also had some results after October first, which we can discuss next week. So yeah, I think we have agenda for a couple of meetings for sure. All right. Thanks. I gotta go now. Thanks. Okay. Okay, thanks. So, thanks everyone. Okay. I got the video published. Bye. Bye.