 So it's been recorded now. Hi. Hi, everyone. I'm up here there and I have been working on improving the performance of the whole strategy plugin for my GSoc project. I'll now show you a small presentation about it. I'm just sharing my screen. So we'll discuss about three things today. Corresponding to the three phases of GSoc, the first we'll discuss about the micro benchmarking frameworks and running micro and GMH benchmarks in Jenkins, both for plugins and now even for the core. Then we'll talk about the performance improvements to role strategy plugin and then we'll finally discuss about the new folder authorization plugin. So there were a lot of reported performance issues in the role strategy plugin. So this is where this project starts from. So what we did in the first phase was to create a benchmarking framework for Jenkins which would enable users and plugin developers to run GMH benchmarks. All of these benchmarks, this framework is now available through the Jenkins test harness to everyone. And we have several methods for making it easy to run. We have an even profile for running the benchmarks locally and we have a build step in the pipeline library for running it on CI Jenkins IO. And we can use configuration as code to configure the instance that is started for the benchmark. So this basically works from the Jenkins test harness. And we have a profile in the plugin form which both get inherited to the plugin. For example, we had benchmarks in the role strategy plugins which are run as a part of the CI pipeline and we started improving the performance from there. These benchmarks on the CI Jenkins IO instance are run using the run benchmark step that was added to the pipeline library. And we have added the ability to use configuration as code to set up the instances that started for the benchmarks. Now, we'll discuss about the improvements to role strategy plugin. So we made a couple of major improvements. The first one was to avoid matching regular expressions again and again. So role strategy plugin before version 2.11, it used to match all regular expressions that were there for the given role type for every permission checking request that it got. So to improve the performance, we now cache the collection of roles that match a given regular expression. And we take care of the invalidation of the cache which gets invalidated whenever a new role is added or modified. So this has given us a lot of improvement in the performance. And the benchmarks which were created using the benchmarking framework show us improvements of about 3,300%. The other change we made was to cache implying permissions. So the permission model that's used by Jenkins follows a tree-like structure. So one permission can imply the other. For example, there's the administrator permission which implicitly gives the user the permission to read any job. So role strategy plugin used to calculate all of these implying permissions every time it was asked to perform a permission check. And what we do now to improve the speed of the permission checks is we cache the set of permissions which are implied by any given permissions. This happens when the class is loaded for Jenkins when the plugin is loaded. So this does not waste any time at runtime. Now, like I said, we measured the performance improvements using the benchmark framework and they were visualized using gmh visualizer. After all of these changes, we were able to have a performance improvement of about 10,000% in our cases, in our test cases. These were some synthetic benchmarks and some of them were user-provided benchmarks. So we covered them all there. And to make it even better, we created the brand new folder authorization plugin. The plugin has just released last week and is now available to everyone through the plugin update center. And this freezes from the backward compatibility of role strategy plugin. And just like it, this also supports global roles, folder roles which are like project roles from role strategy and agent roles for configuring permissions to agents. Robled roles are just like role strategy plugins global roles and they become applicable everywhere in Jenkins. Now, what we introduced here is folder roles which work on folders from the folders plugins. And the permissions to a folder plugin are inherited to all of the children. Agent roles, next we have agent roles which allow us to configure permissions for multiple agents that are connected to Jenkins. And we have REST APIs for managing roles and with swaggerages and support. We also support Jenkins configuration as code out of the box. So this is what a typical configuration from configuration as code looks like. And this is the swagger API. This API is available through Swagger Hub and you can download steps for running these API calls from multiple languages. Now let's go for a quick demo of the folder authorization plugin. So let's just first log in as the admin and let's go to where we manage a role. Now we can just add roles here. So let me just add a role here and the role was added. This is the longest screenshot. It took a while. It looked like one year switching to the demo. Yeah, now it works. Yeah, so I'll show it again. I'll add another role here. And you can assign multiple permissions to the role and the role gets added. You can assign any SIDs of the users to the role and the SID gets assigned. And you can see all the permissions that this role gives us. Now let's just show how the folder roles work. So we have a couple of roles. This is the configure, the less important job role, which allows user one to modify all jobs data inside folder one and its style folder. And now this provides all the permissions to modify a job. And we have another one that allows user one and user two to read the job. So let's just log in to user one. Now what we see here is there were actually three folders, but this user only has access to one of them. And now when we come here, when the user gets the read access to folder one, he or she automatically gets the read access to all its children. Now let's see this important job. And the user does not have any permissions here. But if you remember what we did when I was showing the roles, we have the less important job here. And the user gets the permission to build and delete the projects. In the same way, for agent roles, we've given user one the permissions to delete agent one. But the user does not have the permissions for agent two. Now let's just switch to the Swagger Hub REST APIs. So this is what the Swagger Hub API looks like. We have a YAML file here and this lists all the REST APIs that we have. So when you go to, when you want to look at a particular API, you get the full JSON schema that you need to send as a request. And you can get some, you can get the CURL API, you can get the server APIs and in CURL, can I, yeah. So you can generate the client SDK in multiple languages. Now, let's just compare the performance of the full authorization plugin with the role strategy plugin 2.13, which contains the performance improvements I already talked about. So the global roles for a test case of about 500 roles is about 934 times faster than the roles in role strategy plugin for checking the permission. And the folder roles for an equivalent regular expression-based configuration is about 15 times faster. You can see this GitHub pull request for our benchmark results. Now, some of the challenges that I faced was to have efficient permission checks. This took a lot of time and my mentors really helped me here. So the global roles permission checks now happen in a constant time. That is a big one. Now, the other thing was configuration escort support. So the data-bound configurator in the configuration escort plugin did not support import, did not support either import nor export of sets. So there were a couple of pull requests there. And finally, the threat safety and safety realisation for the folder authorization plugin was another challenge. So what we did was make the authorization strategy object immutable. You can see the pull request for all of these changes. And finally, I'd like to thank my great mentors, Oleg, Runje and Supoon. And please do share your feedback through either through the GitHub chat or through the Jenkins developer mailing list. Thank you. Thanks for the presentation. So yeah, I'll stop the recording and we can discuss a little bit later. Okay. If you want to, we'll get to this video posted. Thank you. Thanks for watching.