 We are now recording. Hello, everybody. And thank you for joining the 2019 Google Summer of Code Project demos. This is part two. The date is August 26. I am one of the org admins, Marky Jackson. We have a full set of demos today. I am very, very happy and very, very proud. For those that don't know when you're joining, just so you are aware of the Google Summer of Code, it's a global program for the open source community organizations, mentors, and students. There's been 15 years of Google Summer of Code, over 14,000 students covering 109 countries, 651 open source organizations, and over 35 million lines of codes committed. You can find out more about this at summerofcode.withgoogle.com. As most of you are aware, we are the Jenkins organization within the Google Summer of Code. This is our third year participating in the Google Summer of Code. When this started for this year, we started with seven projects. We're now down to five. If you'd like to look at our projects page, you can do so at Jenkins.io, forward slash projects, forward slash G-S-O-C. We have our blogs at Jenkins.io, forward slash nodes, forward slash tags, forward slash Google Summer of Code. And finally, if you'd like to reach out to us, you can do so via the Google Summer of Code Gitter channel. The link is there. I'm not gonna reiterate that for everybody. I would like to extend a huge thank you to our 2019 students. As most are aware, this is a very competitive program. It starts with a lot of students who have great ideas and then we have to boil it down to some of the more finer ideas. That doesn't mean the other ones were not good enough. It just meant that we had to make the choice. And these are our students. They have put in a lot of hard work. Just an amazing effort. I thank all of you students for everything you've done. Your efforts have been noted. They have been praised and we're just so thankful for everything you do. Students Pratchay, Natasha, Nguyen, Abaday, Jack, Prashatek, Ufti, if I butchered any of the names, I deeply apologize, it was nothing personal. And then I'd like to thank the Google Summer of Code team. Things that really might not be known is we're always looking for ideas. We love to help and mentor. We're looking for students. We're looking for mentors, technical advisors, Google Summer of Code admins, all of these great things. If you have any questions, please do not hesitate to reach out to one of the org admins, one of the mentors. If you feel that you don't want to reach out in the public channel, please feel free to directly message one of us on getter. You've also, I'm sure you've seen our emails in the Jenkins dev as well as the Jenkins Summer of Code Google group. So please don't hesitate to reach out if you don't want to do so in a wider form. You can also contact us. You can look for our information at jinkans.io forward slash projects forward slash gsoc. So we're gonna jump right into the day's presentations. Today we have Pratchay. He will be doing the GitLab branch source, multi branch pipeline support. We have Nancy who will be showing us the Jenkins pipeline for the open risk project. That's the Libcore CI. And then we have Slaydence who will be doing Jenkins configuration as code plug-in developers tools. I would like to make a note, there has been the outreachy presentations that have been postponed for this session two. We do have an open doodle for a session three, which we will be presenting out to the community very shortly, probably when the next day or so. So with that, I am going to turn it over to Pratchay. Pratchay, take it away. Hi, thanks, Maki. Okay, I'll just share my screen now. Okay, hi everybody. Welcome to the presentation of GitLab branch source plug-in. So this plug-in was developed as a part of Google Summer of Code under Jenkins project. So officially this is the team. So this is me, Pratchay. And this is Maki, Justin and Joseph. So together actually we did a lot of work collaboratively and it was a nice experience. So this is the official team, but entire Jenkins community, Oleg, Martin, Jesse, Gavin, everybody put efforts to this plug-in. So I just want to thank everybody for their efforts. So yeah, so we have after three months, we have the final release of our GitLab branch source plug-in. So a brief introduction about it. So this is a lightweight plug-in which lets you easily configure your GitLab server on Jenkins. And we have support for configuration as code, which is jcask and you can do that by using YML. And the main part, which is multi-brands pipeline and folder organizations that has been also implemented. And with that, generally before what you had to do is using for in your GitLab server, you have multiple projects and in that you have multiple branches, tags, merge requests, et cetera. So for that you had to create additional jobs. So right now you just don't have to create job, what you just have to create one job and that manages everything from triggering the builds on update events or you can just trigger it from your GitLab server and et cetera. And you can also create the job using JobDSL which is a movie script. We have also the new SEM trait API that basically lets you configure your jobs and we have implemented new APIs that were requested by our user and this is quite powerful and lets the plug-in be more extensible. Okay, so this is what we did in the phase one. I'll just quickly recap what we did in all the phases. So in the phase one, the GitLab API plug-in was developed and there was GitLab server configuration part of the plug-in, which also allows you to create GitLab personal access token inside Jenkins. Also, you, Jcast support was added, repository was incrementally defined and Java 8 compatibility with stream APIs and there were three enhancement and fix releases in this part. So in the second part, there was implementation of grand source. So we had a lot of features, including checkout credentials, status notifier of GitLab, these traits like subgroup projects, discovery, you can skip notification, override hook modes and discover tags. We have also worked on reducing the API calls which increases the performance of the plug-in and we had two alpha releases in this part. And yeah, so phase three, which is this phase that this code got completed and in this, it was more about fixing the bugs and adding some of the missing features based on user's feedback. So webhook support was broken. So we fixed it. It basically lets you trigger the job on GitLab events and system hook support is also part of GitLab support which will let you create different jobs, different repository in your GitLab server and Jenkins will detect it, create this webhook on that and basically add it to your job if it's configured that way. So this was, and then trusted permission strategy, it is a security feature that was recommended by older. So what it lets you to do is sometimes the fork request can be from untrusted users. So you'll not want your CI to be broken or some secret details to be shown up publicly or anything which is damaging your security. So trusted permission strategy will only ensure that the users of having access level of developer, maintainer or owner access level will be allowed to trigger the build and some other trades like you can trigger the build with comment on your MR. Sometimes the externally server fails to build. So this is also a user requested feature and log build status as comment. This was also added because sometimes the GitLab server has no feature for the status notification, for example, fork merge request. So this helps. And we have also added the JKS and job DSL documentation to the repository and that will help users to configure the plugin. And on this we had three beta releases and based on the testing of our testers and our users, we finally had one, one GA release and I'm glad to say that so far we do not have any bugs reported, but I do not say that it's totally buggy, but yeah, so kind of it's a use in products and scale. Okay, so I'll just quickly show you a demo of it. So I have a script in that, the organization folder here. So the script I'll save it and then we select build now. And yeah, so the build has been completed. A new project has been created here based on our configuration in the script. So I'll just select the scanner group. You can see the configuration here. You can see the configuration here with all the support of the trades that we configured. Okay, so you can see the scanning. Oops, okay. Okay, so maybe there is some issue that I am facing. I do not know why, because I tested the same script and it should be maybe with some, okay. But that's fine, Protsy. Don't worry about it. Just keep moving on with your presentation. You're doing a great job. Okay, so we have this. So you can just go to the repository. You can, we have the instruction there and you can just build it yourself and test it out. There is more to it in the documentation. There is all the description, how to configure, et cetera. And we have all the GA related also here. You can just test it out. So some of the statistics in the three months, we had two contributors. We had four at nine comers. There were 111 issues out of which 95 were fixed. 55 full requests were made, 2.5 installs of GitLab API plug-in, 125 installs of GitLab branch plug-in so far. And there were 12 blog post outlining all the weeks work. And yeah, so you can just, if you want to talk to us about any issue or any feature request, you can just drop your mail in our developer mailing list. I'll be keeping a track of that. And you can report issues to the Jenkins Zero with GitLab branch plug-in component. And you can also join our GitHub channel. So you can just tag me there or anybody who's in there. Okay, so this is what I plan for the future. I'll be actively maintaining the GitLab branch work plug-in. So I am also planning to add GitLab support in Blue Ocean. And then also I'll be exploring ways how Jenkins CI can be modernized in the sense that I think the front end can do improved as well as Jenkins can support additional text tags that is being avoided these days, a lot of them. So I will explore ways by taking feedback from the Jenkins users because I am not a particular developer user. So might be some user feedback would be more helpful. And so my exploration would be on that. Okay, so this is all about my project. So if there's room to ask any questions if you have any. Thank you very much, Prachya. I'd like to thank you for your massive effort that you put forth in this. You were as one of the mentors for this project, I will have to say very self-managed itself. You did just a phenomenal job and you're just very good person to deal with. And I love your demeanor and your positivity. So thank you very much for all of your effort. Does anybody have any questions either here on the recording or via the Gitter channel? I am looking and I don't see that we have any questions on Gitter. I have a question. So it's a little bit about a question about the extensibility aspect. So this was originally developed for GitLab, right? From an extensibility aspect, is that for, excuse me, for any sort of SEM or is it for just like other Git providers? It's about the plugin job functionality like some of the traits that have been developed like skip notification, this is a part of job like it notifies, it makes additional configuration to your job, like you do not notify your GitLab. So that can be a different plugin. That way extensibility. All right, thanks. Does that answer your question? Yeah, I think so. It sounds like this is a bit more generic than I was thinking. Yeah, it's kind of generic. Okay, that's good. I like that. That was a good presentation, by the way. Okay. I have a question about the comparison with GitLab branch source. So from your point of view, what is the feature overlap? What is missing in GitLab branch source? Or are they on par with regards to features now? Okay, so far I think all the features that is there in GitHub branch of plugin, it has been covered in GitLab branch of plugin and we have some additional features as well. And some of the features that you might find missing here, it's because maybe a GitLab server does not support it by default. So, but in my knowledge, I think all the features are completely. That's great. Thank you. Okay, just a heads up. I mean, just now I re-scanned the same configuration and it just somehow started working. Yeah, so if you want to show the demo now, why not? Yeah, thanks. Okay. Just show your screen again. Yeah. Okay. So, so this is the scanned job. So let's see this part of the slide. So here there are two projects that has been discovered. You can go to the folder and it's basically folders and here there are jobs for all the branches, most requests and tags. Okay. So this is the tags and you can just go ahead and see the output of this thing. So let's see that. Okay. So, okay. Am I sharing my screen now? Yes, you are. Okay. So, so I'll just go to one of, so you can see that the comment has been made on your merge request that Jenkins has scaled. You can just write Jenkins rebuild. So this was made on the 11 merge request and a build has been triggered. So you can see that. So it was basically the issue with the Jenkins file. So the build will generally fail because that's how it is. But sometimes external failures occur. So in that case, you can just rebuild it. So yeah, that'll be all for demonstration. Yeah. If there any specification of current commands supported via commands? You mean the rebuild? Yes. Yeah, you can modify the common body. I mean, Jenkins rebuild is done by default, but a user has the flexibility to modify it. So just to share some context on that, it was basically how can something quite wait for GitHub last week. Because here we have issue BCI Jenkins, I always rebuild so there. And the idea was to partially replicate interface from pro because your pro is one of engines for Kubernetes which also supports command talks. And basically this is the only mode it supports. So I had interest to have similar interface for Jenkins. For me, it was Jenkins rebuild, but it was mentioned in the beginning. So maybe once it's ready, there could be some opportunities for somehow merging these features maybe on ACM API level or maybe on something like that. Yeah, yeah, that's possible. I think I'll discuss with Stefan who's the maintainer. Yeah, because I think with GitHub plugin, I'm not sure if this is still the case, but I know I had to install the pull request comment build plugin in order to get this functionality for GitHub. So it's nice that it's a trait that's just kind of like available for you. You don't have to go search for it. But yeah, pulling that down to like an ACM API or the cool. Yeah, maybe not ACM API, but high level API. So yeah, there are some discussions about this. So maybe we could do that. Let's collaborate later. It would be a nice opportunity. Yeah. Awesome. Does anybody else have any other questions? Okay, well, thank you very much, Pratsha. I very much appreciate everything that you've done here. Okay, thanks. Thanks, everybody. Next up, we have Nancy. She will be presenting the Jenkins pipeline for OpenRisk project, which is the LibCorp CI. So Nancy, I'm going to turn it over to you. And if you want to go ahead and share your screen and take away the presentation. You're on mute. Yeah, thank you. Am I audible? Yes, go on. Yeah, okay. Hi, everyone. This is Nancy. So my project is continuous integration for hardware projects on LibCorp CI. So this year, I did my GSOC with Fawcay Foundation. And so I had this, like this is a very great idea to have a CI for hardware projects. So we have our automation server as Jenkins. And I worked on the Olig and Stafford. So, okay. So I'll be just presenting it. Yeah. So Fawcay Foundation, just a brief interview, just a brief introduction about Fawcay Foundation. It's a nonprofit foundation and it promotes and assists the free and open source digital hardware designs. So you can go through the link and you can see other hardware projects. So we have an idea regarding LibCorp CI. So I worked under LibCorp CI. It's an approach service to provide continuous integration to hardware projects and totally powered by Jenkins. So as we can see from the diagram, so we have like, we can maintain all the, we can maintain all the hardware projects, the CI regarding hardware projects. So this summer, I worked with OpenRisk, OpenRisk community. I worked on, I worked on Integrate. I worked on CI for OpenRisk, which is a family of free and open source processor implementation on the Risk architecture. Yeah. So we can see, this is the whole diagram which can, which can brief about LibCorp CI. So it's powered by Jenkins and we have a predefined Docker images which can be used for the various, for the various configuration of various hardware projects. So projects, they connect their infrastructure to LibCorp CI and there's a quick setup of nodes by project maintainers. For example, I developed some Docker images for OpenRisk projects, specific to OpenRisk project. So just to recap of first phase, so first phase was all about, all about enhancing the CI pipelines because it previously worked on Ravis CI, so I just moved it to Jenkins and for that I created a Docker container for that, which has the environment for all the, for it to run. So now the OpenRisk CI runs in Jenkins. Then about the second phase, yeah, so the second phase was about working on your synthesis. So your synthesis is for all the hardware projects, like it's for hardware world for the RTL synthesis. So I worked on your synthesis and there was a, there were changes in code description file of the more one cakes, which is one of the project of OpenRisk. So what do we mean by code description file? So we worked on Fusoc. So Fusoc is a packet, is a packet tool manager, which is a, which is a very great tool. So it provides everything for FPGA and hardware tools. So there's a code description file in which we have to define everything, what we want and your says, so we have a backend of your says in Fusoc. So we basically have to define in the code description file that we want to use your synthesis. So the backend is edelize. Now, during this, when I wanted to integrate your synthesis in OpenRisk project, we had to do, we had to face many, we had to face many issues, which led to developments. So that, so the issue was that we wanted initially, we wanted to try only for monitoring resource usages. We don't want to go to hardware. So we wanted to make it flexible so that we can use only for monitoring the resource usages and also for the hardware projects if we have hardware connected FPGAs. So kind of, so we made it flexible. So there were developments in edelize, which made it flexible. And now we can, we can monitor the resource usages for any hardware project. So the, the new released version is this. Then we come to third phase. So third phase was, so third phase has a, had a great progress. So I could complete your synthesis and I could publish its result with plot plugin. Earlier I was using performance plugin, but then I came to plot plugin because we were generating a CSV file because I created a parser, which can, which can take, which can, which can output, which can take the data from losses.log file, which is quite big and can provide the printing statistics, like how many wires and how many processors and all the resource which are used in our particular hardware projects. And we can publish it using plot plugin. Then, so due to this, there's a new release version of Libreco CI based Docker image, which is a standard Docker image for Libreco CI. And so this version has the new feature, which is your Sysmetrics parser and it can be used by any hardware project. It can be used by any hardware project who wants to have this feature of your synthesis, wants to see the monitoring, wants to have the monitoring resource usages. Other than that, we use tap plugin, Jenkins tap plugin. So my work was to convert the test results into tap format and then publish the results of tap plugin. Yeah, so other than that, I wanted to make it generalized for any hardware project so that not only for open risk, it can be used for any hardware project. So first part was inside, even open risk is a huge family. So I created, like I worked on creating a pipeline library so that it is generic for all the projects which comes under open risk. Other than that, the main thing which I worked on was your synthesis, generalizing your synthesis. So I created a pipeline library which was generalized for any hardware project and it can be extended if we want to connect FPGAs to see the PNR matrices. So it can be configured for various hardware project with a simple declarative call. So these are the results which I want to show, like right now for any hardware project, we can visualize the project, we can visualize the result in this way. We can have a cell count, so yeah, this is by using plot plugin, this is by using tap plugin. So I just want to describe brief about the pipeline library I worked on. So this was an open risk pipeline which is generalized for any open risk project. So I created this pipeline, we just have to define the job, we just have to define certain parameters. Then we have few socks. So I worked on generalizing the few sock invocation so that it can be used by various projects. It just chooses a base Docker image with few sock which we can define in our library course. It adds the library, it runs the few sock steps. Then we have your synthesis report. So your synthesis report, so I added this in our library course pipeline library. This is quite generalized, we just need to define the core of any hard to project the target, the log path. And we just need to have a simple declarative call and we can have the whole your synthesis process going on with the results which will be published on Jenkins. So this was about the project. Yeah, so what did I learn in GSOC? I learned about various technologies, Docker, Jenkins, Jenkins is a great tool. I think it was quite, I think like having this whole idea of CI for hard to project was possible through Jenkins because it's open source definitely and we can do anything with Jenkins like self, we can have a self hosted setup. Then I learned a lot about Ruby programming, developing Jenkins library, concepts of DSL, then obviously various idea tools. In the end, I just want to say like we invite more hard to projects to use the LibreQuest pipeline library because I worked hard to make it generalized so that it can be used by various tools, various biggest projects, especially if somebody is interested to have process synthesis. And if you're interested, so please reach out to us in GitterChat. Here we have all the links and I've described my most of the work in blog post. So yeah, in the end, I want to thank you, my mentor, Oleg kind of supported me a lot with all the queries, Stafford, he's the core maintainer of OpenRisk. For C Foundation, OpenRisk and Jenkins organization definitely to provide me an opportunity to present my work. Thank you very much, Nancy. This is a very great body work, really awesome. I have a couple of questions. When you ran your test on this, did you run them against, can you just talk about how you ran the various tests for this? Yeah, I can just, am I, my screen is shared to you? Yes, it is. Yeah, yeah, yeah, thank you. Okay, I'll just show the, yeah, I'll just show the pipeline. So this is, I created, so basically, this is for more one case and I did a configuration, so we can see that. So it's a simple configuration. We just need to call this step, like the OSIS report. And we just need to set the parameters, just save it. And when we build it, so I've already done this because it takes a lot of, it takes a bit of time. So I've already done it for the presentation. So we can see that we have plot graphs for cell count. We can see different parameters. For example, SBLUTs, SBCarries, which were part of this hardware project. So we can visualize all that thing. We can compare the results according to the dates. If we have any, yeah. And also for resource usage, like public wire bits, wire cells, memory bits, yeah. Are there any, are there, is there anything on the roadmap for other tests that you want to incorporate or plan to incorporate into this? I'm sorry, can you please elaborate a bit? So I see that you're doing like for public wire bits and the memory bits. Are you going to incorporate it? Do you see anything else being incorporated for the use of this? Like what other cool things can this do? Like what other things can be added to it? Yes. Yeah. So I think this can be, so as you can see, okay, I'll just show. So I can extend my pipeline library. So you can see that this is, right now this is only for monitoring the resource usage. Later, if somebody wants to see the bit stream, like I want to have the bit stream pass or any other parameters when FPGAs are connected. So we can extend this pipeline library to have that feature. Okay, thank you. Does anyone else have any questions? All people think maybe I couldn't have you work it's about the project. Yeah, so yeah, basically it's when you work this hardware, it means that you work on not only this hardware, but there's dozens of different technology chains, including software, various continuous integration, DSLs, et cetera. And Nancy's project is an example of that. So she was working across multiple GitHub organizations with different roles, with different practices, and these completely different technology states. So it's ideal and it is for hardware projects. It's a lot of scripting in Python, in Bash, if I recall correctly. Plus it's Docker, plus it's Groovy, Pipeline, also some Java, because we needed to dive into Jenkins code in some cases. So yeah, there was a lot of collaboration across multiple organizations. And it was probably the most challenging part of the project because yeah, we were working in so many different areas. But Nancy did really well. So basically all main goals of the projects are delivered and we've got some improvements for LibreCore CI as a generic framework. There is still a lot of work to be done there, but yeah, it's going great in the right direction. So yeah, thanks a lot Nancy for all your contributions. Yeah, and actually it was sudden that we started working on this project, not in May, but in December it was. So Nancy reached out to LibreCore organizations earlier and yeah, we had a lot of contributions which I'm not least of in the current presentation because yeah, they were done before the J-Soc time frame. Really, really awesome. Thank you for all your hard work Nancy, very much appreciated. Okay, next up we have Slayden. Am I saying that first name right? I feel like I'm totally bullshitting. Yeah, yeah, yeah, perfect, it's perfect. Don't it Slayden, you got it right. Awesome, awesome, cool. Whoo, made me feel good there, thank you. So up next Slayden will be presenting on the Jenkins configuration as code plugin developer tool. So I'm gonna go ahead and turn it over to you and you can start sharing your screen for your demo. Yeah, cool, okay. Can you see my screen? Yes, I can see your screen. Yeah, cool. Okay, so yeah, so I'll be presenting the JCAS DevTools project. This project comes under the Community Bridge which was a Linux foundation initiative that was just started. So as we all know, JCAS has a lot of support writing YML files directly without touching the Jenkins UI. So the JCAS project, actually, one second, just let me move the screen forward, okay, cool. So things I'll be presenting here will be just an introduction about what I do, what am I studying and stuff. The problem statement about what things I'm missing in JCAS, whether I'm dealing with the broken schema, the developer tools I'm going to implement, et cetera. The Community Bridge, what is it all about? What are the goals for the phases? Since we have just two phases, because the second phase is, to be honest, it's quite huge. And the status, so I'll be demoing some, whatever work I've been doing and the future plans, of course, okay, so let me just go, yeah. So I'm a third year undergrad from Mumbai University. I've interned at quite a few companies in the past. Most notably, the Open Mainframe Project that's currently going on, actually, that's another initiative by the INUX Foundation. And that deals with all of S390X systems and stuff. So a lot of CFC++ programming. And I've worked for Cloudyboss, that's an Australian startup. Quite a lot of Java there as well. So as you know, since Java is quite a strong background, Jenkins, I was naturally attracted to Jenkins as a project. You can find me on GitHub. And of course, my personal website, if anyone is interested. So let's move on to the community bridge. Okay, so I came across the community bridge project. I think in the Outreachy channel, which on which I will like quite frequently post updates. So I reached out to him stating that, is there availability for the community bridge project? And he told me that there was, he gave me a range of projects and said that JCASC is one that they have all of the foundations to undertake. So the community bridge project is one that is hosted by, it's a new initiative that is by the Linux Foundation. And it has a host of projects under it. So under which Jenkins obviously comes in. So yeah, cool. Okay, so the goal for the community bridge project basically is two phases. First is the JSON schema validation. So as we all know, we write a host of YML files and we have no way of validating whether what we're writing is correct. So maybe you write some YML file and you realize there's a typo somewhere. So Jenkins neither does VS Code, nor IntelliJ warn you that the YML file that you've written is wrong. Unless you load it up into Jenkins and then Jenkins says that it's invalid while trying to load it up. So part one of the project deals with the JSON schema validation. So basically fixing the JSON schema that was, that is currently generated by Jenkins and validating it. So it needs proper validation before Jenkins can load up the configuration and configure all of the plugins. And the second one is the most requested and most favorite feature actually, the auto-completion for JCASC. So we run into while coding developers basically, we are so used to auto-completion VS Code in IntelliJ and various such IDs. So it would be, we had ID auto-completion for JCASC, where we just maybe type in system and system message and stuff and Jenkins just auto-completes it for us, how cool that would be. So for assisting me on this project, I have three wonderful mentors, Tim, Joseph and Oleg, who will be guiding me throughout this project. And since it's just, I think 20 days since the project started, we're quite initial, we're quite in the initial phases of this project. So I'm not going to be introducing groundbreaking features right now, but yeah, over time I will. So, yeah. So a little bit about JCASC, for those who don't know, I think everyone does, but still. So JCASC allows you to write, yeah, YML files right out of the box, no need to, there's no need of clicking on different UI buttons and writing system messages, maybe writing, maybe configuration of different types of plugins. We have so many plugins and Jenkins going in and configuring each one, writing their messages or how they behave. Instead of doing all of this, you could just do this. So write Jenkins, system message, number of executors and all of your plugins. Suppose if you have maybe the credentials plugin or maybe something else, you could just open up a YML file, load it up and load up the JCASC plugin and just hit load. And this would configure the UI without you using any, without you using your mouse basically. So moving on, okay. So phase one, so it's been 20 days since phase one started and we have been working on the generation of the schema basically. So the current schema that is generated has been written in jelly files. So basically XML, executable XML. So the jelly, the files that are currently being generated are actually not up to the draft standards. Whatever files that have been written, they don't validate at all. So my first task was to actually fix that. So what I've done is we have, we decided that instead of following the entire jelly approach, we would rewrite it in Java. So rewriting in Java has its own advantages. It becomes easily testable right of the box. It's easy to debug going line by line. If you find anything's wrong with the schema, you could easily just fix it, make up a full request and submit it. Okay. Some of the other things that the jelly files do is they make it very hard to debug because there are different jelly files being called in each of these, in each of the execution steps by the DSL plugin. So it's quite, it's very, very difficult to maintain. So we decided for a rewrite in Java. So the works are done so far. So since we decided that we would require a rewrite, we decided to start right from scratch. So basically to generate a schema, we need the plugins and for each plugin has its own configurators, its descriptors and so on. So we decided the approach that we were going to follow is take all of these plugins, take all of their configurators and basically whatever sub configurator or sub attributes they have, we would just kind of take generator JSON object and then generate the schema accordingly. So these are step one and step two, that is to generate the schema configurator-wise and basically make sure that we follow the jelly approach. So we just didn't want to reinvent the wheel. We just followed what the jelly files did and basically just wrote it in Java. And it's not easy as it sounds because the jelly files do a host of things and to replicate that in Java is kind of very difficult because it's not easy to understand the JSON schema. Okay, so now demo time. Let me just, one second, let me just, okay. So this is the original, if you can see my screen, yeah. So this was the schema that the current jelly files generate. So as you can see, it doesn't validate very well. You can see a host of errors here. So this is an online tool that I'm using to verify that the JSON schema is correct. So you can see that it should be an array and there should mismatch in schemas and one-offs. So you cannot actually write anything here. So that it kind of, it's kind of no use actually, to be honest. So what we did was we generated the schema in Java and it's just six version six, as you can see. We decided to go with the latest version, I think version seven or it is six, you decided to go with version seven. So as you can see the schema generated right of the box is valid according to draft seven. So we are making progress in that aspect. Apart from that, since this schema, you cannot validate anything against it, no matter what you write, it doesn't, the schema is invalid, so it doesn't matter. But here, as you can see, since the schema is valid, you are allowed to make change. You can actually verify that the JSON that you're passing is correct. So now you'll be wondering why am I passing a JSON? So what we do is we take a YML file that Jenkins has and we convert it to JSON and then validate against the JSON schema. So as you can see, we have our Jenkins, I've taken a very, very simple Jenkins YML file. So as you can see, if you write a system message, maybe hello world, yeah. So a number of executors is two, yeah, boom. So the document validates against the schema. So this is a valid schema. The moment you decide that your number of executors should be hello world, bang, should be an integer. So yeah, so basically this is what we have done so far. We've managed to make sure that basic nesting simple, level one nesting is valid. The moment you shift on to more levels of nesting, it becomes quite difficult to validate the schema because as you can see, we've followed the jelly format. So that didn't handle nesting very well. So that is one of my future goals that I'll be talking about in my presentation. If I could just go on, yeah, future plan because I'm done with kind of presenting some of my work. The future plan would be, first of all, to fix the nesting. So support nesting of YML configuration file. So as you go deeper and deeper into Maven generations and JDKs and stuff, we need our validator to kind of validate all of that. So that is actually phase one. I've put it in C, it's not priority wise, but still this is priority number one. Priority number two is to figure, invoke validation before application. So basically now there is no validator, I think as Joseph told me. So we need to maybe validate it before applying the schema so that it's much easier for the developer to figure out what he's doing. And the third one is addition of custom configurators so developers can add their own configurators according to the plugin. So basically we were thinking of developing some sort of an API where the developer just puts in his plugin and we just pick the descriptors, the attributes and stuff and just bang, we generate the schema according to our requirements. So phase one ends in approximately two weeks. Oleg told me to be a bit careful with the future plan. Hi, I'm careful. So yeah, apart from that, yeah, thanks a lot for the presentation. Feel free to chat with us in the DevTools project. There's not a lot of members there. So kind of feel free to put in inputs there. Yeah, that's about it. Any questions, please? Any questions, anyone? Questions? I can ask some. Well, yeah, basically I'm not a mentor in this project as a team and Joseph mentors. I help a bit mostly as organizer of community bridge. But yeah, thanks a lot for a slide and a slide for working on this project because it's a new experiment for us. It's also really available to the community because the Agents Configuration School is a new brand. We've got more than five sample installations since it was announced and yeah, it's just skyrocketing. So they're released every week. Some releases may break the configurations and it's really essential for users to have access to schema so that they can validate the configurations before applying them and same for development tools. So basically my vision is not on the IDE auto completion but also validation and the deployment in the IDE. So for example, as a user, I can take one idea like say visual studio code or intelligent idea and I can manage my instance from there plus all kinds of development tools for configuration management. I mean automated configuration management. So yeah, it would be the end goal and the project just starts. So there is definitely a lot of things to complete but there was already some progress and this is it. So thanks a lot for that. Yeah, yeah, thanks a lot. Very good work, Sliden, very good work. Anybody else have been? Yes. Hi, this is Martin speaking. I want to know, how do you generate the schema? Like is it hard coded or is it extracted from? Is it extracted from automatically? No, no, no, I could actually share my screen if you want to have a look at the generation. Is that okay? Yeah, that's fine. Cool. So yeah, Martin, we actually pick up the configurators basically from each and every plugin and so the type obviously since we need them to be, since the basic configurators are objects and all of the nesting comes under it. So we're basically picking up most of the configurators and having the types already hard coded and as we go into nesting, that is the problem actually as we go into nesting. So we need to define their properties properly because if we get any of the properties wrong, the nesting doesn't work and your schema isn't of any use. Although it will be valid, it won't be of any use. So this is what we are trying to work on that when we go into levels of nesting, that is once we put in the properties that the further kind of integrations that are done for the schema are actually valid and the nesting is probably done properly. That's what the jelly failed to do actually. The jelly files failed to actually incorporate any sort of nesting and they're just kind of bare bones separated from each other and when you kind of try to validate it, nothing works. So that's how we are trying to actually generate. That's great, thank you. Yeah, welcome. This is great work. Does anybody else have any other questions? I don't see anything in the chat nor in the getter channel. Well, I'd like to thank all of the presenters today. It was very awesome. I know everybody has put in a lot of hard work to this so I am very, very happy and I'm very thankful for everybody. So definitely take a moment, take a bow for yourself and be thankful for what you put forth. This concludes our presentations for today. Does anybody have any questions in general about anything that they've seen that they would like to talk about? Does anybody have any questions about just the Google Summer of Code program that they would like to talk about? Yeah, how to join? Say again? How to join? Yes, thank you. Well, since you asked, I will go ahead and let everybody know. So we have a Google Summer of Code getter channel. That is one way you can join. Another way is you can send an email to our, we have a Google group which is a Google Summer of Code Jenkins All. If you don't want to ask outright, you're more than welcome to approach any of the mentors. I'm sure the students would love to talk to you. The org admins will talk to you all day long so be careful if you're out there. I joke when I say that. Please feel free to ask any of us what we can do. There's so many projects that we have. There's so many ideas out there. So what I really would like to say is as a lot of you understand that the Jenkins project is an open source project. We try to be very diverse. We try to be a very inviting community and very helpful. So if you feel that you, I don't want to ask in public, talk to one of us. For any of the people that were at Jenkins World, you'll know just the org admins I can speak for, we are super, super approachable. And by and large, this community is very approachable. A lot of our SIGs need help. We need more people. We cannot do this project as a whole without everybody chipping in. Even if it's something as little as working on a doc, we're just asking, hey, I only have an hour, a month, that I can dedicate. What can I do? We will help you get involved in the open source community, but more so towards the Jenkins Google Summer Code project. If you are interested in this, if this sounds awesome and you'd like to be a part of what you've just seen here, please do reach out, either via email, do the Google Summer of Code all, or via Gitter. At the Google Summer, we have it's called gsoc-sig. You can reach out to any of the org admins. I want to thank the org admins. This is a very dedicated thing. We spend a lot of time making sure this is good. I want to thank all of the mentors. We don't get paid to do this. Everybody dedicates their time to make this. But more importantly, and by and large, none of the Google Summer of Code is possible without the students. What you all do is nothing shy of amazing. Because you put forth, you take sometimes the criticisms, but the guided, of course. It is so awesome that we're now coming to the end and to think this started what seems like an eternity ago. So thank you all very, very much. And I would like to just give you a round of applause. And thank you very much. Would anybody else like to add anything? Well, I would like that we will make sure to post all links in the meta page. And if you want to contribute to even with LG so there is a number of opportunities. For example, in one month, they will be October 1st. And we will make sure to participate. So if you have some ideas for smaller projects, especially for newcomers and those former experience contributors, let us know. Because we can use them as a source for October 1st and other hackathons we want to organize all of the year. Well, that concludes this presentation. Also note that there will be a third presentation for the outreachy things that I mentioned at the beginning. There is a doodle currently going around to firm up the times for that. So do look out for that. If nobody has any other questions, that concludes this meeting. I thank you all for taking the time out of your busy schedules to sort of celebrate our students. Maki, I'd like to add a thing. Yes, please. OK. So hi. So if any of the future aspirated guys are looking into this video, I would like to suggest you to participate in GSOC. It's a really nice experience. I learned a lot in the three months. Like I worked with a lot of people. I learned them. I learned about them personally. So it was really nice. And so just a personal experience that I also got a job because of Jenkins. Yeah, GSOC is itself a really nice addition to your profile. But in addition to that, being a part of Jenkins, which is really popular in the organizations that use it. And so it really is a nice organization. And mentors are really helpful. So I'd like to request if you ever want to participate in GSOC, please do consider Jenkins as one of your choices because you may like it and you want to participate. Thanks. Thank you very much, Prachi. Yeah. And of course, we should say thanks to Google as well because GSOC is not free, even if mentors don't get paid. Organizations get some stipend. For example, we use the stipend this year to sponsor free supply of students to Jenkins World and other conferences. So yeah, all of the stipend still goes to the sponsoring student projects. But yeah, also, our students get stipend. And basically, it's still tens, thousands of dollars invested by Google just in Jenkins project. And also, Jenkins is just one project. There are hundreds of projects this year. So yeah, you can imagine the scale. And yeah, thanks a lot to Google for running this initiative. And yeah, it's 15 years of GSOC this year. Hopefully, there will be 16 years next year. Yeah, so let's see. That's as old as Jenkins, isn't it? That's how old Jenkins is, too, now. Yeah, Jenkins is also 15 years. We had a cake at Jenkins World United States. We did. We did have a cake there. OK. I'm looking forward to Lisbon. Lisbon is going to be very good. Yeah, fingers crossed. OK, if there's nothing else, I thank everybody for joining. I will go ahead and stop the recording at this point. Have a great time, everybody.