 Okay. It's been recorded now. Hi, everyone. Welcome to Jenkins Summer Project Demos. So, yeah, it's quite an unusual session because this time we have presentations by three projects. We will have presentations by Google Summer of Code students, by outreach students, and also by community outreach students. It's a new program started by Jenkins Project recently. And, yeah, we just have one student. But, yeah, today we have four presentations, and all presentations are about JSoc. So, probably, yeah, I'll just switch to my screen share. This is my screen? Yes. Okay. So, yeah, today it's about Google Summer of Code, mostly. And I'll spend some time just to say what is Google Summer of Code, because, yeah, not everybody knows it. Google Summer of Code is one of the biggest programs for open source organizations. Basically, it provides students opportunity to work on open source projects and to get mentors from open source projects. So, students get a student and basically they work full time for three months. And, yeah, there are also additional things like community bonding. So, yeah, it's a pretty big project. To Southern Titan is a 15th year of JSoc, or during the timeline of the program, there were more than 16 Southern students. You see everything on the slides. But, yeah, basically it just warfs any other open source program available now. And Jenkins Project is happy to participate in Google Summer of Code. 2019 is the third year in JSoc. Before that, we participated in 2016 and in 2019. For us, this year is also the biggest project. We have seven projects. We started from seven projects. Five of them have reached final evaluations. So, five projects will be presented today and on Monday for JSoc. If you're interested to know more about Google Summer of Code, we have a sub-project page for that. You can just navigate to our website. And here you can find information about all projects we have. You can find contacts like mailing list, chat, which we're using for all kinds of communication. And if you're interested about a particular project here, you can also navigate there. For example, if you're interested in remoting, you can go here. And here you can find links specific to the remoting channel. So, yeah, you can use this site as a landing page. So, yeah, I do not want to spend a lot of time on introductions. So, I would like to say thanks to our Google Summer of Code students. All of them spent a lot of time on the program. They spent a lot of time to apply to prepare and all of them have delivered really good results this year. So, we are happy to present them to the public. In addition to that, we have had dozens of students who applied, who made some contributions as a part of application. We had many mentors working with students, around 30 mentors this year. And, yeah, also thanks to all other contributors who helped to make these projects happen. If you're interested in JSOC, as always, we look for mentors for students and for project ideas. So, yeah, if you have an idea of what you would like to improve in Jenkins and you have no time for that, maybe Google Summer of Code is an opportunity because basically if you're ready to mentor, if you can find other contributors who are interested in the project, you can run it. And this year we have several examples of such projects which have been facilitated by individuals. So, yeah, it's a great opportunity. Okay, today we have four presentations. So, we'll start from presentation by Natasha about plugin installation manager. Then we will have presentation about flow strategy performance improvements, about work in house plugin, and about remote in Kovapache Kafka. Before we start, does any of our students want to add something? I would like to say thanks to all the students for their hard efforts. Super, super amazing. Thank you very much for a summer well done. Thank you to the mentors and the org admins. Thanks for everybody being here on the call to watch this. It's very, very awesome to see all of us come together. Yeah, right. So, if you have any questions during the presentation, you can use Zoom chat. I believe it's enabled. Is it? Yeah, there is Zoom chat. So, you can just ask here if you have any question. You can also go to our Gitter chat, even after the presentation, and we have all the contributors around there. So, you can also ask questions here. We will be monitoring it. In addition to that, if you want to join other projects, other presentation, there will be another online meetup on Monday. So, you can just use Zoom online meetup. I believe this is the original source where you find these links. Here, there is another meetup on Monday. So, you can just subscribe for that, and we will have another four presentations there, or maybe five. Let's see. So, yeah, right here. Okay. That's it from me. Natasha, are you ready? Yeah. Okay. So, yeah, you can just start to screen change. I have a quick question about Zoom. So, I have it set up so that I can, like, just switch, like, desktops for my Mac. Is there a way I can share my whole screen, or do I have to select, like, an application to show? Yeah, share button. Sorry, go ahead. Share button, share subcontract screen by default. Oh, okay. Gotcha. Okay. So, can you guys see my screen? Yes, we can. Yep. All right. So, hi, everyone. I'm Natasha, and today I'm going to be talking about the progress that I've made in the last month on the plugin installation manager library slash CLI tool. So, just a quick overview for people who might not be familiar with the project. There were a couple, I guess there were two sort of main goals of it. The first was to improve plugin tooling. So, being able to allow users to set up all their plugins before an instance of Jenkins even starts. And then to also try to make that process easier and more transparent and give users better control of which plugins they want installed. And then the second goal was to create a library that could then be reused across different areas of Jenkins where plugin management is done. So, just a quick recap of what I did in phases one and two before I get into the details of what I've done for phase three. For phase one, I sort of started this process of converting the Jenkins Docker install plugins bash script to Java and then created the basic structure and skeleton of the CLI and library. And then phase two worked on just trying to refine that. So, improving the parsing and the Docker compatibility, and then also being able to view more information about the plugins that you're going to download both figuring out, I guess, what plugins are going to be downloaded prior to download, and then seeing if there are any available updates or security warnings for those plugins. So, phase three mostly focused on cleaning up and adding tests for a lot of the stuff that was done in phase two, but there were also a couple new things and improvements you try to do as well. So the first of those was just improving the plugin download speed. So in kind of the first versions of the Java tool plugin download speed was significantly slower than the original bash script. So we worked to try to speed that up and make it almost comparable. And then the next thing was just if there are any issues downloading or resolving the plugin dependencies, just throwing an exception sooner instead of waiting until it ends. And then previously, user could sort of either specify that they wanted to see information about plugins or download them but not really do both at the same time. So we try to make that process a little bit more flexible by just adding an option for the CLI tool to specify if you want to skip downloading. And then we also added a check to see if the Jenkins war version is lower than what's required in the plugin metadata. So I'm trying to find some issues before you even start Jenkins. And then I'll talk a little bit more about this later, but I was also able to attend DevOps World Jenkins World to present my project. So that was like another thing that I did this coding phase. Okay, so I'll just do a quick demo of some of the newer features that were implemented. Okay, so here I have, I'll just show you I have a plugin file with the plugins that I want to download, or see I guess in this case just sort of see information about them. So in this case, I'm going to list information about those plugins. So being able to see what are all the, what's the final set of all the plugins that would be downloaded, and then do any of those have any security warnings. And then this was, we also had this new CLI flag where CLI tool flag where you can specify that no I don't want to download these plugins right now I just want to see this information. So just do a quick demo of that. So we're going to go get all that information and you can go ahead and display that without actually downloading them. And conversely, if by default, the plugins will automatically be downloaded so you can go ahead and list that information and also download them at the same time. So this is, this was based off of feedback given from some of the other community members that doing more or less having the default to download but being able to see that information at the same time was useful for using this in Docker. And then the other thing that I was going to demo is more or less seeing if you have version compatibility between your Jenkins war file and your plugin. So, in this case, we specified the Jenkins war file, and then I also specify the verbose option so you can see more information about that. And then I also requested this plugin the workflow support plugin. So if we take a look at some of the metadata for that so for the workflow support, you can see that the required core is 2.121.1. And if we go ahead and run this you'll see that our Jenkins version is slightly lower. So this will go ahead and throw an error and let you know that this plugin requires a greater version of Jenkins than the war file that you specified. Okay, so I also just wanted to briefly talk about my time at DevOps world Jenkins world because that was another big part of what I did this coding period. So that conference was four days in San Francisco, and I was able to present my project during the CDF contributor summit and the Jenkins community lunchtime demos. And then when I wasn't presenting I was able to attend sessions talk to community members, what the note let them know about my project and get some feedback. So it was a really awesome experience and thank you so much to Jenkins and cloud bees for giving me that opportunity. And then I have a blog post that I wrote about that that I have a link to at the end if you want to read more about that. And then the last thing that I just wanted to touch on is, it's not always smooth sailing so there are a couple challenges of this coding phase as well. So, in the original script, if you have two versions of the same plugin, then the newer version will direct or the higher version of the plugin will directly replace the lower version. And if you have any dependencies of the lower version that aren't included in the higher version, these never actually get cleaned up so you can end up installing some plugins that aren't needed. So this is something that I tried fixing, but this ended up being way more complicated than I realized it was going to be so. Yeah, so I still don't have like a full solution for that but I just wanted to kind of share that was something that was tried to do and ended up being more difficult than anticipated. Okay, so what's next. We're really close to releasing the first official version. So hopefully within the next week we'll go ahead and release that and then submit a PR to the official Docker image to get that incorporated. So be on the lookout for that. We're really close and hopefully that'll happen pretty soon here. Okay, so here's some links and more information. So I have linked my project page and then the Gitter chat, the repository and then I also have a link to that blog and the PR that I mentioned that ended up being pretty challenging. So I think that's all I had. Are there any questions that anyone has? We have one question from Jesse Glick in the chat. Is the plugin manager able to share between Maven, for example via Maven repository directory? Sorry, do you mind repeating that? Yeah, I can just put it to the chat. Okay, so you can find it in JSOC chat on your own? Okay, so yeah, not currently, but if that is something that would be really helpful for people, he's more than welcome to submit a jura ticket. So right now, we don't really have any compatibility or support for Maven, but that's definitely something that other people have requested. And yeah, I think that's a really good idea. So that's something we can look into for sure. Any other questions? Thank you Natasha. By the way, Jesse should be on the call. Yeah, so yeah, I have another question about the library part. So yeah, CLI works pretty well. And yeah, we're looking forward to have the final release adopted in our falls. But there is also a library part. So what's the current state of APIs and whether it can be consumed as a library now? I think it's close. I guess I would, yeah, I think it could be started to be incorporated in other areas. I guess I definitely want maybe some confirmation on that, but I think it generally works pretty well. So yeah. Yeah, I guess I feel free to look it over and I guess you could tell me if it's close. I think so, but I would just want like, yes, some kind of confirmation or I guess a little bit more information about that. Yeah, so the reason. Oh, sorry, I was like, I think it can be because the development was done. Tasha did a good job of separating out the pieces that were involved with the CLI into its own separate module. And the library does all the processing and the plugins. So as well and it's well Java docked. So I think you can use it as a library today. If you needed to. I just started custom work packages to do zero work with a good opportunity to try it out. Yeah. That'd be great. Thanks. So any other questions? It's not. Would you like to add something about the project? I guess like it's, it's was a really great summer. And I think Natasha did a really good job. The tool is already being used by some people so that's, that's really nifty to see it, you know, actually helping some people's work flows already. And it was really like her presentation to sell the pictures and sell the blog post it was really interesting like nifty to be able to go do. And talk more about Google Summer Code and share what she's done. So good job, Natasha. It was, it's been a great summer. Thanks. Thank you. Any other comments? actually can also say like thank you to everyone in the community who's helped with this project as well. There's been a lot of like really great community involvement and I think it's one of the shows like the best parts of open source. I really wanted to highlight as thank you everyone for helping out too. Thank you. Okay our next presenter is Mbuda Sharma. He will present his project about role strategy performance improvements and other projects which are apparently part of this project. I'll just share my screen. Okay, can you see? Not yet. Okay, now it works. Hi everyone, I'm Abhide and I've been working to improve the performance of the role strategy plugin for my GSOC project. So let's just discuss three things into this presentation. The first one is running micro benchmarks in Jenkins plugins and recently it was added to Jenkins core. After that we'll discuss about the performance improvements to the role strategy plugin and then I'll introduce about the new folder authorization plugin. So the project was initially started because there were a lot of performance issues reported to the role strategy plugin. Most of them were basically due to repeatedly checking regular expressions and checking of these regular expressions wasted a lot of time. So let's start with the benchmarking framework first. So the benchmarking framework allows you to run jmh benchmarks that is Java micro benchmark harness which is an open JDK project and this framework is now available to everyone through Jenkins test harness 2.51. We've added a couple of other things to make it easier for all developers to integrate this into the plugin. So we have an even profile in the plugin pump for running benchmarks locally and we have a pipeline step in the Jenkins pipeline library for running them during a pull request build on CI Jenkins IO and vSupport configuration is scored for configuring the instance that is started for the benchmarks. You can check out our blog post to learn more about how to run these benchmarks. So we added the main profile for running the benchmarks to plugin pump and Jenkins test harness contains the benchmarking framework and configuration is scored plugin version 1.21 added the ability to configure these benchmarks using configuration as code. Then we added the pipeline step to the pipeline library and this was all implemented in the road strategy plugin. So all the benchmarks are run as a part of our pipeline right now. Now and these benchmarks helped us to improve the performance. So there were a couple of major changes made to the road strategy plugin to improve its performance. So the road strategy plugin for every permission checking request that it got. It used to calculate and go through all of the regular expressions every time. So to prevent that we've added a cache of the roles that match a given regular expression. So this cache gets invalidated whenever a new role gets added. So it maintains the coherence of data. So this has given a significant performance improvements and so basically this was a trade-off between CPU time and memory and the jmh benchmarks in the plugin show improvements of up to 3,300 percent. The next change we made was to cache the implying permissions. So Jenkins permission model follows a tree like structure and one permission can be implied by the others. For example, there's the Jenkins administrator permission that gives all administrators the access to read any job. So whenever the road strategy plugin was asked to check for a permission to check if a user has a permission it used to calculate all of these implying permissions. So to avoid doing that again and again we added a we store these implying permissions when the class is loaded. For Jenkins that would be when the plugin is loaded and we can access them whenever we need. We used the jmh benchmarks for measuring a performance improvements and these reports were generated during the pull request build and the results were visualized using jmh visualizer. So now after all of these improvements we were able to see performance improvements in benchmarks of about 10,000 percent. So these are synthetic benchmarks as well as some benchmarks for use cases provided by users. You can check out these pull requests for the benchmark results. Now let's go on to the folder authorization plugin. This was a brand new plugin that was created during GSOC to avoid some issues that were present in road strategy plugin and the 1.0 release was launched and is available to everyone now. You can check out the blog post on the folder authorization plugin to learn more about it. This permission this plugin freezes from the backward compatibility of a road strategy plugin. So some features of the plugin are just like road strategy we have three types of roles. We have global roles which are applicable everywhere inside Jenkins and we have folder roles which work on folders from cloud based folder plugin and they can be used for multiple users and multiple folders. The major feature of folder roles we have is the permissions through a folder role are inherited to all of its children and finally we have agent roles for configuring permissions for agents connected to Jenkins. For all for managing roles we have REST APIs with swagger JSON support and we support Jenkins configuration is scored out of the box. So this is what a configuration is scored YAML looks like for the plugin and you can check out some more examples inside the folder authorization plugin. We have the swagger API for the plugin which allows you to download stubs and tools for running these APIs from multiple languages. Now let's go for a quick demo of the plugin. So this is what the plugin configuration screen looks like and so you have global roles and you can add roles. Similarly you have folder roles and agent roles. So we have a couple of roles here. We have an admin role which gives all of the administrator permissions to users and we have a role which gives the overall permissions to all authenticated users. For folder roles these folder roles can be added on multiple folders so let's just talk about the couple of roles we have here. We have a role which works on folder one's child folder and this applies to user one and user three. This role gives the permission to to cancel, create and delete the job here and we have the read folder one which gives user one and user two the permissions to read the folder one. If we go as the admin to the home screen, yeah so we have three folders here and let's just log in as the user one to see how it works. So the user one does not have the access to the other two folders and when we go inside the user has permissions for reading all items inside this folder which were inherited and so if we go to this job the user would not have the permissions to run a build or create or delete anything here and if we go into the child folder you can see that the user gets the permissions here so you can just run the build and delete the project. So similarly through an agent role we gave this user permission to delete agent one and so as you can see here the user can delete the agent and for agent two he does not have the permission so it's not here. After that I'd like to show you about Swagger APIs. They're all hosted on Swagger Hub and you can download the configuration from here so this contains all this the schemas of the post-request that that are used to modify the roles and if you add the server here for doro engine instance it'll generate curl methods and command line and in various languages so you can download the client SDK and interact with the plugin. So let's just compare the performance of the folder authorization plugin with that of role strategy two not one three which contains all of the performance improvements that I earlier mentioned about. So the global roles here over the permission checks for global roles are up to 934 times faster than the global roles in role strategy plugin. This was for an instance with 500 global roles and 500 users. For folder roles the permission checks are 15 times faster than the equivalent regular expression implementation and role strategy. This was obtained for a benchmark in which there were 250 projects which were organized in two level d-folders on an instance with about 150 users. So you can just check out this poll request here for comparing the benchmark results and knowing more about these benchmarks. So some of the challenges I faced here was to have efficient permission checks. So it was really hard and we had a lot of discussions with my mentors to produce an efficient solutions for these permission checks. So as a result the global role permission checks are now happening in constant time. That is a big role of one. The other thing was configuration escort support. So configuration escort plugins or data-bound constructor did not support export or import of sets. So a couple of poll requests were made to the jcast plugin and these were released in version 1.24. The next challenge I had was to have safe serialization and to have threat safety for the modification of roles. So we implemented all of these API calls by making the authorization strategy object immutable. You can check out the poll request to see how this was implemented and I finally I'd like to thank my great mentors Oleg, Runje and Supoon. Thank you everybody. Please do share your feedback suggestions and comments to me through either the role strategy plugin getter chat or through Jenkins developer mailing list. Thank you. Thank you for the presentation. Are there any questions? We have one question in the getter chat. Yeah I can pronounce it. So JC says that you shouldn't have passed configuration escort plugin. It's that role strategy who should have been normalized to use at least instead of sets. What do you say about that Abhida? For us sets gave us enormous advantage in checking whether a role contained a given SID or not which helped us to get the to check if the if the set contained the users SID or not in without going without going through all of the roles that were there. All of the states that were there. If we were to use okay so using sets simplified how we would serialize the object but looks like there is a connectivity issue maybe on my side. Can you hear me? Yes we can. Okay so I don't really have an answer for that because this was not something we discussed during the project. So I think we can go over the folder authorization plugin and try to see how we look to fix that. Yeah so just to add to Abhida's response. Yeah usage of sets is not widely but there are several use cases for that. Not on the role strategy plugin on on the folder authorization. So from configuration escort perspective it was really useful to have this patch. So we added compatibility for few more plugins and also we another patch delivered by Abhida allowed us to pass empty collections on nulls which simplified many configurations for jcascusers. So I think that for us it was really a good improvement even if it was not strongly necessary in this particular case. Okay so yeah another question from the zoom chat is a question from Martin. Does the role strategy plugin have anything to do with the regular expressions? Viewing regular expressions as in? What I mean by the view is in Jenkins there's folders but there's also as I guess as a legacy feature in Jenkins there's different you can create different views that they look like tabs at the top of the top of the jobs that are described down below. That's my question. So role strategy does not allow you to configure permissions for views right now. Okay there are global roles which give you blanket permissions for managing those views but you cannot manage them for individual views. There is a long spending feature request for that in a role strategy plugin but due to multiple complexities mostly in the web UI it has never been integrated so maybe later when we have better web UI and the next presentation will be by Jake who will talk about some opportunities for that maybe after that we will be able to easily expand to other item types using Jenkins. Okay any other questions? Okay then I'll let a few words as a mentor and yeah this time a video presents before Parishay so I hope that the first marking. So yeah basically it's this project went really well and yeah I would say that for me it felt rather like two Google summer off codes because firstly we got a performance benchmark engine which became a part of the standard Jenkins tool set with all the documentation with even pipeline library integrations so basically it's ready to be used by any plugin maintainer and for me only that felt like a fully completed Google summer off-code project and Abideh was able to do that during the first code phase and after that there was a lot of patches to different components a lot of collaboration in the community so yes there were important changes in the role strategy plugin there is a new folder authorization plugin creation of new plugin wasn't in our plan it was initiated by Abideh and I believe that it's really good for Jenkins users who want to get better performance for folder based setups which is quite common nowadays in addition to that yeah we've got a number of patches in configuration as code plugin not on the deployed patches which were mentioned today in the presentation so I think this project has a huge value to the Jenkins community and yeah we've worked really well collaborating in the project in the community we had maybe a dozen of contributors involved at different stages so yeah thanks a lot Abideh for me it was a really great project and yeah I'm looking forward to continue after GSOC if you are interested thank you thank you thank you so much for your support throughout GSOC okay thank you too any other words to it anyone so yeah let's move on to the third presentation it will be a presentation by Jack Shen who will present new improvements in working hours plugin and also some new approaches to work with react-based plugins in Jenkins yeah yeah I'm here can you hear me yeah okay and I'm gonna share my screen okay can you see this light yes yeah okay and okay hi everyone this is Jack from working hours plugin and this is the the third presentation during this summer and today I'm gonna share two mirror things and one is the working hours plugin updates and the other is the boiler the react-based plugin actually is a reactive plugin template okay and for working hours plugin and the all of the updates is we add holiday presets to the plugin and we add presets manager to to help is to help the developer to extend presets and using this presets manager and we also add Chinese holidays and in the long run we can add any preset any holiday presets we want and the other is the test and we add excluded date test and the time range judgment test the current status of the working hours plugin is will it will be released in a week approximately before August at the 13th and the second part I do really want to introduce is the react plugin template this is a boilerplate project which which can help develop Jenkins plugin UI with react and this is also which is extracted from the working hours plugin during this summer so while using a reactive plugin template there are many reasons the first maybe we need to make the plugin UI much customized because like traditional Jenkins plugins are using a render system like called jelly and it doesn't have so many JavaScript like interfaces or some extensibility to help us to help user to enable user to make the UI customized and we may just use some have some already defined components and if we use react we can take a full control of the UI also the second some new developers may prefer modernize the tools like react instead of jelly and because as for me at the first time I tried to learn about working hours plugin and then I found it's based on jelly and that takes that really takes me a lot of time to get familiar with it and also I believe that most newcomers to build Jenkins plugin may be much familiar with react or any other advanced JavaScript frameworks like Angular or Vue and so it may take a lot like a lot of cost to learning how to develop plugin in jelly so maybe and so so for this I'm thinking about making a template to help the newcomers to develop their first plugin also plugins dependency may come make have lots of conflict things like versions because if on one single page like there are two plugins want to share this screen and they like sometimes they will always use browser import is just like a link in the HTML and these two packages if they're used a different version if they're used two different versions and the later version will like will override the first version and it will cost lots of conflicts and the another reason will be poly fields like prototype.js and they are edited before like a long time ago and it may block us using some new browser feature like you know many browser eyes are supporting like some advanced array methods like map and list and some other for example take map for example and the map defined by prototype.js is really different from the process map function and which may cause severe problems also we want to use npm packages to optimize workflow and you know there are so many there are so many useful packages so this this is the templates features we we got react integrated and so we can take focus of the ui we and we use iframe and it can create a new javascript environment we can show the desired effect of of some poly fields also we this the template has integrated npm commands into maven lifecycle with the help of front end maven plugin also we use webpack and it can help us reduce the size of the bundle and it will also avoid some pollution on the global namespace and it just will be an instant called function and also we are free to make requests and we don't we can use uh because crumb is a text crumb is a like genie's token is attached to a axios client and for now we can send requests in the way we want to use also we and this template gets expressed as a dv server and it will enable the user to run the react app in a standalone page and it will get many features like livery load and request a block proxy and also axios as the hd client is a powerful client so how does this template work it's just like putting a webpack project inside a maven project and this it's just by it's just the chaining the view the results the result is something like html and javascript files and it just be copied to the plugins web app folder to make it accessible from the iframe it's just like the diagram though first we use webpack to bundle the react project and then we paste the output to the source slash web app folder and we then link it link the static files in iframe like the link below and then the iframe is rendered by jelly and the results can be shown as the react is running in browser also while using iframe yeah and the javascript has a long history and from when and maybe at that time the jsp or jel is what they used to render some web pages and it a lot of follow feels like a prototype and is provided by that was provided to give extensions to the script but for now the javascript extent the beta is much stronger than before but they are all added to the global namespace and if we simply mount our react app to a certain point it will be disturbed from on many javascript methods but iframe is using a new environment it's like a shield can block the conflicts from the the other from the from the other libraries and the interference can be avoided then this template also has an integrated Jenkins Chrome to actually be client as Chrome history is default enabled in Jenkins to prevent cross-site request and each Ajax request is required to contain Jenkins Chrome in the request header and we use the plugin UI to render the jelly and it says Chrome header and Chrome token to that frame and then then the access instance inside the react project that can grab header and the token and then attach it to each request header and then we can make any request we want to also we can use lots of react libraries this two screenshots is from working hours plugin and on the left is the react data picker and the right is a library called a library called assyslider to in this we use it to create a slider for user to choose time range and this is the template and i add an entry in the management link in the management system management page also and this is the plugin UI it's the template UI and the current status the template has been transferred to Jenkins CI at this this link and there's a blog post about the template is being reviewed and maybe maybe need maybe need more feedbacks and okay thanks for watching and that this is all i have today yeah would you be able to show some examples of working hours plugin in live uh i'm not running working hours plugin uh for now i but i'm running the the uh the template for now and the link is managing we this is the main entry for the react plugin template and the side the template this is just a simple to do list yeah and yeah so maybe we could have them after presentation by long if you're fine with it um sorry uh so um yeah if you could present it after the presentation by a long so maybe in 20 to 30 minutes 20 it will be great but yeah if not oh oh yeah yeah yeah uh maybe i'm gonna i can run that after the long okay yeah yeah and uh and maybe for now that's all from that part okay yeah so any questions uh to jake thanks we have a few questions in the getter channel but i think that might be something we could take offline uh they're from jesse so i think maybe uh jack and jeff can answer those yeah that's all there was one comment about moving the template to archetypes so jinks project have an archetypes repository where we have templates for common tools like pipeline libraries etc so one of the comments from jc was about moving jack's template there once it's finalized and yeah another comment was about homograves but in different sense to take you to find okay any other questions or comments um hi guys sorry sorry i joined late i've i've been actually without internet most of this week we're at the beach but i have but right now i just wanted to thank jack for the the work he did on this plugin i think it's a great addition to the plugin and i'm hoping that it will help other people that want to use react to their ui's to get a jump start yeah thanks thanks jeff thank you and uh really jinkins web ui is one of uh pretty well known issues in jinkins yeah there is a lot of attempts to improve that using various approaches like for example bloatian plugin or embedded solutions like warnings next generation plugin mentioned by jc in the gitter chat uh so yeah there is already a lot of jinkins plugins using react and for example last year we had a code coverage api plugin which also uses react in order to display coverage statistics and the details in a fancy way so there are definitely ways to do that our problem that we have no unified way and framework well we have some jinkins design template and something like that but it would be great to have a framework which can be easily consumed by the plugins and yeah jeff did a really great example of how it would be used and i'm looking forward for this project to continue and there is another question from frank in the zoom chat about customizing parameterized building pages so right now build pages yeah i'll probably answer this question because it's not strictly related to the plugin so right now jinkins pages are either written in jelly or in groovy except installation wizard but yes once we have a stabilized framework we also could improve this page right now you still can customize it for example using a simple theme plugin but yeah this is a partial solution at best so yeah a simple theme plugin allows adding custom css to change the style or it allows adding javascript to the advanced thread in the ring so it would be the recommend approach at the moment yeah yeah that's right yeah and also i i i got my example running my running working hours and maybe can you maybe you can see it now oh yeah if it's yeah you're not scrunching right now okay i'm james ring i think yeah this is the working hours plugin and here's some we added one thing the chinese holiday presets and and in the holiday presets that are here at first there are no some like chinese holiday and this and i added some this is a chinese holidays and then manually uh as a new chinese holiday manager and then this is the that's how they can apply it they've got a new it has presets the set state it has already automatically 70 days and then we can save that and it will exclude that on maybe next year's June 25th and and i'm below and above this is a 10 range and down below is the exclude dates we can add more much exclude dates yeah and all these few days wait will will be will be will be excluding the good jobs uh when when it's uh when the rule judge today is sort of excluded and that's all for the working hours plugin yeah i think the big part it will be the template yeah thank you and that's all for tonight for this part there is some worse jeff would you like to add something about the working hours plugin so i was kicked out of the meeting so i'm not sure what what he um what jack presented i can i can basically describe why it why it was created so so the idea is that if you have a job that that actually deploys to production which my most of the teams i've been on have done um you might not want that to happen on holidays or in the evenings um it's probably better to have that happen during the day when you have all the engineers around so it basically just gives you a way of providing times when jobs will be queued so so if somebody emerges a pr in the in the middle of the night it'll wait till morning before it actually runs um are there's some other questions i i guess since i was out of the meeting for a bit i i miss i don't have a lot of context that's fine thank you okay if there is no other questions or comments we can proceed to the next presentation okay let's continue our last presentation from today is about is from long about the remote think over apache kavka uh but these were just next improvements already okay hi everyone uh today i i would like to present about the first three of remote think over apache kavka with kubernetes future project and uh first i would like to reintroduce myself i am long uh from i'm a university student from vietnam and my mentor for this project are andrey and kit uh voodooan and supoon and ola is also a technical advisor for this project and the proposal for the project was um uh was also the the previous version of remotely over apache kavka blocking requires user to manually configure the entire system which have the keeper and apache kavka and uh remote in asian and it also doesn't support dynamic asian provisioning so user has to manually add asian to scale the build and this project and to solve that two problem the first one is a solution to provision uh apache kavka and the second one is uh dynamic asian provisioning in kubernetes cluster and uh phase one summary uh in phase one i implemented the first objective which is launching apache kavka in kubernetes feature and i also arrive a skeleton for ham chart this is the web ui so user can input the kubernetes connecting information and press the start kavka on kubernetes button and everything will be set up after a few minutes this is the class diagram and in phase two i implemented the second objective which is uh cloud api to uh so after phase two we can dynamically provision remote in kavka asian in kubernetes and also a completion of the ham chart and supporting of configuration escort this is the web ui of the cloud where user can um can type in the connecting information to kubernetes cluster and uh also the information about remote in kavka asian and this is the class diagram and uh in phase three uh finally uh we have released version officially released version 2.0 and uh there is a blog post on genkin.io and also i also implemented a new feature which is retention strategy for cloud asian retention strategy is like the amount of time that asian will stay idle after running the job before terminating and in phase three i also write a lots of unit test integration test to bring up test coverage to 70 percent and i added jacoco to the maven project so we can check for the coverage in a monthly module maven project and here we can using jacoco we can see the instruction coverage and branch coverage and the instruction coverage is uh roughly 70 percent and okay uh live demo so you can find the instruction to run the demo in the redmi.md5 so the demo requires a kubernetes cluster and here i will use minikube and ham install on kubernetes so we run this command in root directory all this command do is it will download the ham dependencies and install the ham chart and after after installing it will output the instruction to get the password yes the url and like using genkin configuration as code to config as you like and we can check the installation with qtl so here we can see uh kafkin is already running and genkin is initializing and genkin might take about two to three minutes to initialize and while we are waiting for genkin let's talk about the demo command it will use a custom value in this file and what the custom value for demo is for for demo i will disable persistent on both kafka and genkin to use notepad for service install uh drop dsl plugin and also i will pre-configure the kafka local url into keeper url and configure a demo job which is to drop a command echo hello world and for kafkans we keep making standalone running standalone mode to save memory okay let's see the genkin logs so we can get genkin's password by running this command and we can get genkin's url by running this command but uh i'm running minikube on max so the Kubernetes is running in a virtual machine so i have to use the virtual machine address it's that for the node part so here i can see the demo job and uh we can see the to keeper url and kafk url is pre-configured by configuration escode and this cloud to provision remote in kafka agent and uh time to time in minutes to return agent when idle this is the retention strategy and if we set to zero zero then the the agent will terminate immediately after finishing a job okay let's run this demo job so currently we don't have any executor so the job will request of the cloud to provision one worker or one worker is one agent is provision i'm not sure why sometimes there is glitch and genkin's will terminate the agent and provide another another one so this is a remote in kafka agent and if we if we start it via cloud then it will also start us a remote in kafka part in Kubernetes and the agent part we connect with a master part via kafka and it might take about two minutes for for the agent part to connect to master you said it takes around two minutes right yeah which gets connected okay um yeah let's try uh restore the ham again and why we're waiting for it uh let's talk about the future work so for uh okay you can finish and then we can ask questions yeah okay uh so uh for the future work after this so i will switch the local combo demo so local combo demo is updated with the current plugin version and uh we need to switch that and uh investigate about supporting kafka high availability and uh those the right term in long-term plan epic so if you want to answer the question now why not yeah uh so well compared to uh the jnlp agent used by Kubernetes plugin uh i think uh during kafka is um is um slower at first because the first one is have to transfer the draft file was there any was there anything else that you had um i'm gonna i'm gonna demo uh the running of our remote in kafka agent via cloud with uh plugin but the last one has some but maybe relating to uh the new kafka version so i'm trying to uh reinstall reinstall the whole system and try again well if it doesn't work no worries we already have a recorded demo from the previous phase so if anyone interested to see it working uh there's already a recording we can just put a link yeah that would be good okay so long maybe you could finish the presentation uh then if you have some questions we can discuss them and if demo works by then it's fine if not whatever no okay thank you very much for watching mm-hmm okay okay any questions uh too long okay so there was a question uh from uh jc about uh performance have you compared the performance of apache kafka with general perform uh so generally uh i think the the the performance when running job is uh the same because um like it's the same if the the kafka and the agent and jenkin is the same network then uh the transfer the transferring of the classes over kafka is uh small enough to dominate and different and the the agent startup uh time i think is a bit longer than using jnlp to that response so one year ago this put on uh we had some more experiments but basically without uh load testing there was no significant difference between implementations and i believe we didn't do load testing at that fire please turn well please correct me if i'm wrong yeah i think that's right okay any other questions yeah i guess uh there is a uh oh yeah so it was a question about the video i will place the link to the video later in the chat okay uh but on would you like to add something there can you yes we can yeah i think the yeah i mean the last demo for some problem but i think it's fine because uh yeah i mean we can find the video for the second phase already has a demo for the agent so to summarize for the third phase we sorry uh for the third phase we already finished the release 2.0 for the plugin and i think half of the third phase we focused on improving the testing and code coverage for the plugin so i mean in in overall i think long works very hard from the beginning of diesel until now and we managed to deliver the project on schedule and with new features and yeah thank you so much for your contribution and also i want to thank you uh thank uh andrei who is not here today for leading the mentoring effort of the project so that we can have a plugin in the schedule today yeah so thank you so much yeah thank you very much i found the the video link yep so thanks a lot along for your presentation and for your work on this project using jenks with kubernetes is really nice and if someone interested to see helm charts and other components which have been created by long there is a link to the youtube video where he provides more details about them paste it in the detail as well okay any questions or comments from participants if not thanks a lot for watching the presentations and yeah thanks a lot for all the feedback and comments next monday we will have another session with two additional sorry with four additional presentations from google summer of gold that reach and community bridge students so yeah stay tuned for more demos yeah i'll stop the recording then so yeah thanks again everybody thank you everybody