 Well, welcome to the Jenkins UIX Hackfest. At this session, we will be recording demos by Hackfest participants. We have a number of demos which have been submitted for this session. So Felix will be talking about migrating Jenkins config layout. So then we will talk about dark theme, about test environments and evaluation environments for various topics. Wadiq will talk about new script security, approval management UI, and then we will talk about documentation. So this is the current list. If any of the participants want to suggest something, please edit to the list. And we will add that to the demo schedule today. So the session was scheduled for two hours, but I think that we will be done in 60, maybe 90 minutes, we'll see. First of all, before we begin, I would like to thank all contributors. So it was a one-week event and we've got a big number of contributions to Jenkins UI, to documentation and to other areas. So far, we have 42 contributors who have submitted their contributions to our tracking site. This is not a final number because we still have some stories on Jenkins's way. So there are around 10 stories there. Also, there are contributions which have not been reported yet. And if you haven't reported it, please do it because we needed to collect information and you would rather, I want to know it sooner. But anyway, thanks to everyone who has already participated. We have a number of major achievements during this hotfest. So first of all, the Jenkins configuration preview was released on Monday and during hotfest, we've done some testing and some bug fixing. Then there was a dark theme of proof of concept which is now again available for validation and for testing. There were many UX improvements and other components. For example, improved management skills for credentials, script security, folder authorization and many other smaller or bigger patches in different components. Also, documentation migration went pretty well. We've migrated around 40 documentation pages and more than 20 plugins. So from what I've seen and made them up, we'll have more detailed statistics later. And last but not least, we also had eight knowledge transfer sessions for contributors and for Jenkins users where they were able to study modern practices and to get more information about how to develop and improve Jenkins. So what's next for the hotfest? Yes, today is May 29th, but the hotfest is not over. So it will be open until mid-night UTC-12. So basically anywhere on your earth. So if you participate in this session, you still have 18 hours or so, if you want to contribute. Then on Monday, we will also have a few sessions. There will be one session by Slady Nunes about the Custom Jenkins Distribution Build Service at 2 p.m. UTC. On Monday, we will have results session where we'll talk about final statistics and about our next steps with regards to SWAT distribution, feedback, et cetera, et cetera. And after that, we'll just handle and call the logistics and hopefully we'll be able to handle it as soon as possible. So that's the plan. Are there any questions before we place it to the demos? I guess not. So if you have any questions during the demos, please ask Zoumkouni or just chat. We will ask a particular sequence about that question. So give your voice permission so you can ask questions on your own. And there is also a Gitter channel which we will be using for the hotfest. And again, you can use it to ask any questions. So that's it from me. And the next presentation will be by Felix. Hi everybody. I'm going to share my screen. Okay. So I cannot put my video for some reason. It's okay. So I'm going, I want to talk about yet again about a rather interesting and important PR that's been on the works for over a year and with extra push for the last three months which is a PR that changed the form layout from using HTML tables to deeps. This PR there are many changes and these, there are big implications mostly about a free work of JLiquidgets such as for a formentary optional block, script or list, many of them. So I'm going to show you to show how they look, how the new forms look. So first of all, this is the PR. The PR number three, eight, nine, five. We appreciate all testing possible. There's a, there is a github repo just for, with instructions, you have to test this created by Olas, maybe Olas, you can put the link in chat. And yeah, and I encourage everybody to give it a try. Look for complex planning combinations and if they fail, please report it. So first of all, I want to show how the management form looks. This is the big managed Jenkins form, the managed system, configured system. So the first thing you could notice is that the form is vertical. Follows a vertical layout, no more side nesting. Now it follows a nice vertical layout for every section and everything. We are working also to make them narrower so that because it's not really intended for them to be this wide. Yes, we want to optimize for readability and usability for the form. So this is, for example, the user configuration part. Also follows a vertical layout. And here's onto the interesting stuff which are the job configuration. This is a pipeline job configuration. You may notice that there's also some, we are indicating different nesting levels. For example, when somebody uses the optional block Jelly Widget, you will notice the content we think is indicated by this dash line and everything we think it belongs to this parent code block. So yeah, this is how it looks with the grid plugging in the pipeline script from software control management, I forget. This is a really infamous one because it used to overflow and to leave the boundaries of these blocks, not anymore. And yeah, to show for the sake of completeness, this is what the configuration for a free state job looks like, would look like. Keep planning configuration same as before. Same widgets, same nesting. There are kind of widgets still work. Everything sort of works the same, but there may be bugs with certain plugins. Right now, I think we only have one or two outstanding bugs in the whole Genki NCI plugin ecosystem. There may be more and we appreciate any reports and any contributions. Any questions? No questions in the chat. So yeah, one question. So what is the current delivery plan for this feature and what we could do to contribute to that? So yeah, so basically, the plan is for it to be merged into the correct me if I'm wrong, but to merge it to the Jenkins master branch within the next two to three weeks maybe, as soon as possible. And right now it's going straight into master if people find problems or people would rather opt out, we can create, we can try, if somebody would like to commit time into creating an opt out option, it could be an idea, but it's going in. So any, it would be opt out in case somebody wants to put in the work, but it's going in by default. I don't know if that's what you were asking. Yes. Thank you. So, and can you give guidance for those of us who are plugin maintainers? You showed the poster child that I worry about and showed that it has some embarrassing awkwardness in it. I solemnly promise to release a new version that will fix many of those issues, but are there other guidance you want to give us as plugin maintainers to, hey, check this or check this? Is it to look at your UI? Basically, yes, there is one, I have one example for you, for example, here, you'll see this actually, this is the Docker half notifications plugin entry. So you see here, this textbook should be hidden until you select this. When you click it, it should only expand, not overpower everything. And get half, so basically, and the reason for that happening is that this plugin redefines GLE widgets. Basically, this plugin redefines the entry of GLE, optional block of GLE descriptor list. So plugins should use default GLE widgets, as much as possible, and avoid redefining them, especially hetero list is something that's most many times redefined. That's our recipe for having a breaking form, basically. And if there, if any plugin author slash maintainer finds the Jenkins widget API to be too limiting, please be welcome to contribute the change instead of just forking it because it will go out, it will fail, it will conflict, basically. So my problem is I'm not terribly skilled in GLE, can I ask on the Gitter UX SIG, when I have GLE questions, is that the place to go for, gee, I don't understand this or don't understand that? Where should I go to find, to get more education? Yeah, GLE UX SIG, it's nice for, it's a good way for general doubts. And if it's just more of a GLE programming questions, I would welcome everybody to ask in the developer menu list. We are all monitored in that list anyway, for GLE, but I think that's our resource for more developer oriented, I believe. But yeah, we are also paying daily attention to the UX SIG, so any resource would do. Okay. Thank you. So we got one question in the chat. This feature makes a lot of sense for mobile devices. Do we also want to change the menu to be more mobile-friendly? It's a step by step. So right now we're working on the forms. Probably the tables should be next, when we need to make it responsible or responsive. So basic, we're getting friendlier. We will not get there in 100% mobile work in one single PR, but this is a step towards it. Okay, thank you. Any other questions to Felix? No questions. Yeah, thanks a lot to you, to Josh, to Tim and to all other contributors who work on this feature, because it's really big improvement. And not only for mobile devices, but also for narrow screens. So basically everything, which is smaller than the 1,000 pixels. Yeah, thank you. Yeah, we have another question. Yeah, I have another question. So for our testers testing this feature, is there any special things that you would like or know that we should pay special attention to? Yes, if somebody knows of a plugin that has complex UI form stuff, like checking a box, selects another box, checking us, selecting an option, populates a select box in another part of the form. If you know about some of these, please test those specific ones. All right, to make sense. Thanks. Speaking about such type of plugins, does this change currently applied to build parameter forms? So when you trigger a build, you can also specify parameters. And there are many plugins there, which have quite extensive unabinated layouts. Yeah, I mean, the real parameters are supported. If each plugin, I mean, as soon as I lay out for each, for the build for each plugin works, there shouldn't be any problem. Okay. Thank you. Yeah, so just to look up, a plugin that's not adapted to use the git parameter plugin, and it works fine. Yeah, I'd rather wonder about advanced plugins like active choice, et cetera. But yeah, I guess we will figure it out during the next phases of testing. So thanks a lot for your demo. If there is no other questions, we can continue. Okay. Thank you Felix. Okay. So the next presentation is by team. This is dark theme for Jenkins. All right, I'll just share my screen. It's not really much to talk through, rather than show what we've got to. But you're going to have a dark background for this presentation. I would have if I prepared in time, but my computer decided that it's not gonna work in either the restart. Can you see my Jenkins? Yes, we can. Okay. So one of the areas where we've got quite a lot of feedback on in the UX areas for Jenkins to improve was a lot of interest in a dark theme. So we had a bit of a look around to see what dark themes already existed. And there have been a couple over the years, but none of them were maintained anymore. And when I tried to run them, they didn't work in quite a few areas, especially with the new UX reworks. But even some changes from a couple of years ago on the new job screen, completely didn't work at all. So decided to take some inspiration from the Camelot dark theme for the colors and the styling contrasting. But all the code was created as part of this. So what we've managed to come out with is a completely functional dark theme. There's a few issues and a few plugins that need some tweaks or different images. But in general, it works fine. We've tried to make it just a, so less invasive than some of the other themes in Jenkins, like material and Neo, this is using all the Jenkins built-in images. It's, all it's changing is colors basically. So it should be quite maintainable. And we've also done a big rework into the Jenkins core to use CSS variables instead of overriding selectors all over the place, which again should be more maintainable as we don't need to worry about the CSS markup as long as the CSS variables stay in place. And if they do change, then it should be quite a minor change. So that's a short introduction. Let me just take you through a few different screens just so you can see what it looks like. So what you've got, what you can see at the moment is just the Jenkins homepage. There's about a dozen jobs that are created to showcase what it looks like with different sorts of jobs and just build the table up a little larger. You can see that the build queue widget is there. It's got the different nodes. I sort of built executed in the build queue. You've got the pop-out window here. It's all working fine. And the context thing here should be doing something. You've got the breadcrumbs there. You've got the search bar here. And you can click through and go through to the job. So the pipeline stage view plugin needs a bit of work. We're actually just gonna go back and pick one that has a few runs. So pipeline, it's got a few different stages and some runs. So you can see here, this doesn't look the best. But that's all contributed by a public plugin. So it's likely a bit more work. And you see here, all of these icons here and the sidebar work fine. There's one icon we're aware of in one of the pipeline plugins that is using a GIF rather than a PNG. So it doesn't have transparency. So that needs to be fixed in the plugin to use a PNG instead. But that's, I think that's the only issue we've seen. Well, I think it's one or two issues we've gotten related to icons. So it's been surprisingly good. Another menu here, I'm gonna create a job next. You can see the create job experience. And the views work, of course, as well. So to create a job, this is gonna be pipeline four. It's gonna be a pipeline and I'm gonna copy it from pipeline. And you see here, we've got, and so it's gonna have to be pulled in pipeline from the previous one. I can parameterize it and add a string parameter. Alt and trim. So there's another issue here, which is another pipeline control in the plugin. So that needs a fix. And then if I go build with parameters here, you'll see this is what the form looks like and you can see that you can use this. And then if I go to manage Jenkins, so go to the spells, they use a focused view of it. Now if we just go to what an admin would see, to manage Jenkins, all the tiles here, show up appropriately. If I go to manage plugins, the plugin center shows up and some contrast here, the categories, that's all normal. I don't think there's anything special here, but just to show you that you can, I mean what's there, black. And then go back here to configure systems, the main system configuration page, which is a little bit slow, but we're getting there. So you can do a system message and then preview it. And then this is just going through the system configuration page and there's nothing really jumping out. Possibly the info message is a little bright, but it's all functional. So that's pretty much the demo of the running Jenkins. Just to show you where it is and I'm sure of the recent links that you can find. So there's a GitHub repository in the Jenkins CI GitHub organization called dark theme. It's here at theme.css. There's instructions on the GitHub page and a couple of screenshots. So the plugin.css, that's the demo. There is a video link for this one. Yeah, so Oleg has put together a demo folder with instructions on how you can run this as well. You can, I think there's a published stock image and you can also just run inside the demo folder if you want to try it out, it's currently using a pull request on the Jenkins core for the CSS variables change. I think it's looking quite closely merged, so very soon you won't have to do that. And then this will be available for use and we'll release a 001 version. So there's a pull request here which introduces the variables. It's had a few reviews already. And so hopefully it's possibly by the next Jenkins version next week we'll be able to release the initial version of dark theme for anyone to use. In the meantime, you can test it by building a custom version or using the Docker image and just test it and give us feedback. The best way to do that is to create an issue on the GitHub repository. And so we've got a number of issues already open and we've got a number of issues closed as well. So please give it a go and give us any feedback. And thanks for anyone that's done any testing already it's been really useful. Okay, thank you team. We've got a number of questions in the chat. So the first one is you mentioned that we did some changes in the core. Is there an impact for existing themes that were created for the simple theme plugin? No, so it's completely compatible because the changes in the core are just right adding variables and some very minor consistency changes. It's found that some colors were slightly different in certain places and some weren't using variables when the variables already existed. So there's no real styling changes part of it. And we have tested the, I think the Neo theme was tested by Oleg just in case to see if it was. And we've added, so there is one caveat with this that it doesn't, so the dark theme is not going to work on IE 11 because of the features that we're using and we've done some testing just to make sure that IE 11 didn't break because we had to add some fallbacks. But we intend to just maintain compatibility for now but no dark theme support for IE 11. Right, it's also worth mentioning that even if this particular change doesn't break themes, we will break themes soon because there are other changes coming down the line. For example, the story Felix was presenting about migrating from tabs, tables to divs and maybe other stories. So recently we have published a policy for UI themes support and we explicitly say that we're doing the guarantee compatibility. For Neo 2, I think we will be doing best efforts to keep it up to date and I believe the same for dark theme but in principle we don't guarantee compatibility. Yeah, there's another question. How easy would it be for users to make a dark variant of the existing theme? So once this core progress is merged then theme maintainer could migrate over to using the variables rather than having to override all the styling. So there'd be a bit of rework for them in the theme and also very juice of Jenkins versions that are available. So basically you need to use the bleeding edge version of Jenkins to be able to use this. But you can still, they could definitely duplicate they have their existing selectors and then duplicate it with the variables as well and that would work together. So it should be quite straightforward. I haven't shown the code in this but the dark theme code is about 59 to variables plus a theme over 18 hours. Plus we've overridden the theme for the script console as well. Yeah, Neo 2.0 is more than 400 lines in total. Plus there are other images, SVGs, SVGs, various hacks, which allow all the right images, et cetera. It definitely looks great but it might be difficult to maintain it when we start doing all the changes in the UI. So I wouldn't spread that Neo 2.0 theme and other themes you'll also update to CSS variables soon. Yeah, yeah, very keen to keep this theme minimal and using core as much as possible. So it doesn't have to worry about breaking as much. Okay, are there any other questions? Looks like not. So then the next presentation is by me and there you'll be talking about test environments. Am I still online? Yes, you are. I can wait. Yeah, because Tim's screen froze for me so I wasn't sure what's happening. Okay, so I'll share my screen. Oh, do you see my screen? I see about 300 icons. Yeah, if you're a Windows user, that's how you use your desktop because I really, really easy to do. Okay, I'm guilty of that. Sorry, it wasn't the case when I was using MacOS. Okay, let's go to the actual demo. So we had two presentations already. One is about tables to do this migration and another one by Tim about that theme. And both of these areas have one common problem. If you, as a user, want to relate to that, you need an instance which you want to set up and you need to set up plugins, you need to configure the instance just to relate to this component. And for example, during hard test, it was difficult for those who wanted to do UX testing for these components. And as a part of the hard test, I created a few days in my environments in order to support various case cases. So if you have seen previous Jenkins Online Meetups a couple of years ago, I was presenting my demo for Jenkins Configurational Code. It's a repository for demonstrating configuration code and for developing pipelines for CIG and KISIO. This repository is fully configured by configuration code, mostly by Groovy Hooks at the moment, but I'm going to move into JCASC. And this repository includes a number of pre-configured items, for example, jobs, users, agents and also plugins. It includes more than 100 plugins and some of them are pre-configured. So I decided that what if I updated this demo and made it possible to easily test the dark theme or table studio simulations for users. And yeah, first thing I've done, I just updated this demo. So you can see that this demo has been just released a few days ago and this demo now includes support for system read and managed permissions. So this is what was released on Monday in Jenkins Weekday. There was a lot of updates, but basically it includes all the recent versions of plugins, these configurations, and also the support for additional users. So for example, for this demo, you can easily test common admin users, users with managed permissions, users with system reads or just common users. And all configurations are included. And in order to run this demo, you basically just need to make run in this repository. It will build everything and run that. So I won't be presenting this repository because I actually have a demo specifically, let's say for the dark theme. So I kept the extension of this demo and if you go to the demo folder, you can see that this demo is actually based on my demo Jenkins configs code. So it just takes this demo, it overrides the Jenkins Word file because we need one from the snapshot, so which is not released. After that, we install additional plugins. Actually, it's just a simple theme plugin. And then you install additional scripts. So why there is so much additional steps is because we want to support multiple modes. So for example, you may want to just run this demo or you may want to run it, for example, in developer mode so you can develop a theme or you may want to run it with preview user interface. Jenkins Core now we have not only a standard UI, but also preview UI with some experimental features which you could try out and we'll support that. So there is for example, some scripting project which sets additional flags if you want to run development mode or this experimental UI. And after that, there is Groovyhook which basically configures theme, et cetera, based on the main image. So as a user, if I want to test the dark theme, I will just need to run one command make run. And after that, you basically will get the same interface like team presented, but with more plugins, et cetera. I will launch this demo. It will take one to two minutes to start up. It really depends on your operating memory. So in my case, I don't have much one. So it will take some time. What this demo does is basically starts Jenkins instance. Then it installs plugins which are bundled in the image. Then it invokes Jenkins configuration as code, configures some bits of the instance. And then it invokes system Groovyhook scripts and configures the rest because my image has a lot of dynamic logic which you cannot currently configure in jcust. Well, you can, but by doing, by adding group expressions as well. So let's wait for a while. I'm not sure how long, but it shouldn't take that long from this. You can see that there was jcust already. It's quite quick. Then we have Groovyhooks which also initialize our instance. For example, create users, configure particular plugins, initialize demos, identify plan libraries, et cetera, et cetera. So everything is built in. And after that, yeah, it requires some time. Production folder, they configure more plugins, more tools. Yeah, and then enable team. So Jenkins is fully up and running. We can go to our host. And here we get to the instance. Again, I use dark team, but currently allowing a team is managed separately. So it's still yet to be done. And here I will. Just a question, Oleg. Did you mute yourself? Yeah, your sound cut out for me early about 20 seconds ago. So. Okay, you're back. Okay, I'm walking again. Perfect. Sorry, we missed about 30 seconds of your dialogue or like. Sorry. Stopped on the login screen. Okay, so basically what I did, I just logged in as read on the user. So to show you read on the Jenkins configuration with the same demo. And yeah, let's go here. So you will see dark team. You can see that I have much less controls. And apparently I misconfigured my instance. So it doesn't show all the jobs here. Or maybe there is a glitch because it wasn't showing them, and I would show them. I don't know. Definitely topic for testing. But what's interesting here is, for example, manager Jenkins. So for example, if I want to test system, read on the system configuration, this is how I would do that. I kind of, for example, go to the plugin page. I can verify that I have access to this plugin page. But basically I can modify anything. Then I can go to system configuration. And again, I shouldn't be able to modify anything as well. Even if it ever opens. Oh, like the, the scripts that you've got that are doing all this are right inside that repository. They're just groovy scripts that you've got that are, that are doing the between configurations code and. If you go here to my repository, so you can go to any script, and you can see that there is some magic inside. But yeah, basically the main visualization is here. So for example, if I want to initialize my development folder for pipeline development, you can see the script here. So basically checks whether there is already development folder. If not, it creates that. Then it checks whether there is a local pipeline library development environment and BPS. It just initializes jobs and demos in this folder so that I can test it without really committing anything. So yeah, there is some magic I was presented with that previous meetups won't be going deep inside. Some of these demos can be actually replaced by configuration as code at the moment. Not all of it. So for example, he's one example. Here's another example for Docker. Again, you could configure to use configuration as code YAML, but JCASK doesn't support templating now. And here I basically do templating using code of features. So I create a template for Docker image. And then I just have a right this template for common agent and for maybe an agent which sets additional options. I think JCASK does support that in the latest version to a degree with anchors. Yeah, technically you can do templating with anchors. Nice. Thank you. Thanks for showing it. Sorry to derail your demo. You can go back to your demo. I just, you give me hope when I see things like that. Oh, there's even more I can automate. Thank you. Yeah, right. So if you want to try out a demo which configures a lot of things. So for example, at some point we created a demo for called this Jenkins distribution and JCASK. So yeah, it's called Jenkins distribution, but basically it includes the same open source plugins. So here, for example, you can find a long YAML, which configures a lot of plugins. And there are more demos like that, for example, in configuration as code repository. So you can find more examples if you're interested for JCASK. My demo is just a bit old style. Thank you. Yeah, here are all the demos for JCASK. Okay. So let's go back what I was showing. Yeah, I was showing admin configuration. So yeah, you can see that it works. Well, mostly. So for example, these companies are read only these companies read only, but we still can modify them. So there is still some improvements to be done for system read permission. But generally it works pretty well. Even now. Yeah, that's why we have several months before the next LCS baseline. So yeah, you can try it out with this demo. And for example, if you wanted to, if you want to try the UI Felix was presented. I also deployed a demo like that. So basically it's exactly the same. I just copied the demo from the dark theme, spent 15 minutes to update the dependencies. And now there is a demo also for tabs to this configuration migration. So this demo is basically the same. It just uses another baseline at it enables additional permissions. So for example, you can run this common thing is from preview and you can get interfaces Felix was showing, but also this pre-configured set of plugins and jobs. So it's good for evaluation. And actually these demos can be just run by my crown and this may crown if you're interested. It's just something like that. So basically it runs the image and everything is packed inside. So if you want to try out the new features, you can take one of these images and get them running. You don't even need to build them because they are deployed to Docker Hub. Okay. Any questions? So again, we will appreciate all kinds of testing for these new features because there is a lot of changes happening right now. And we will definitely benefit from some additional testing for them. So for example, this is manager permissions, which is also in preview and you can also test it from this demo. And it just doesn't provide the entire conflict. I tested it, it works. But definitely we can keep improving all these configurations and we will appreciate your feedback. Okay. That's it from me. If there is no questions, we can move on. Okay. So the next presentation will be by Vardek. Yep. So if you see my screen, that's good. Yeah. Nice vision. So we are like for the clean desktop. I guess you're looking into my entire presentation. It was just removing two icons, but yeah. So this demonstration is especially about how to manage the script approval. So for people that are not aware of, you have normally some script, some job inside your instance. And sometimes you have some pipeline script. If you are not using the CSM, so the Git integration directly or other CSM, of course, you have multiple versions, multiple possibilities to insert your own script. In that case, it's just inline pipeline. You have also the possibility to retrieve them directly from Git. In this case, if you are doing the configuration with the inline pipeline, you have the possibility to either retrieve the, write the pipeline directly there with approval from an admin or using Groovy sandbox. With the sandbox, you are requesting approval for different signatures. In my case, if I'm using the sandbox, this call to the method println is something that need to be approved by an administrator. If you are not using the sandbox, it's just the full script that is approval nut. So what is the problem with the current version? So if you're going to the in-process script approval management link, so inside the managing in this page, you will see the number of things that need to be approved. And you get to something like this. So a full page of things that you need to approve, deny, and things like that. You have the full script. You have the possibility to approve or deny the different things. And you have some signature that are already approved, the things that you need to approve, and the possibility to clear the previous approval. So that's the previous, the current version if you want. And here, you have the new version that I was working on, and you will see the PR directly there. So the new feature that I'm proposing with that PR is that you can see all the pending approval inside the table so that you can expand the code or minimize it. So you will not put in a page with a lot of noise if you're only wanting to approve one script in particular. For example, in the previous page, you have some script that are not very long but still taking half of the screen in terms of space. So it's not something that you really want in terms of UX. In this case, you just have the number of things that need to be approved. What are also added in terms of a feature is just the size of the script, nothing to really fancy there, but also the request date. So to know better what is recently requested or not could be helpful for the admin to determine the order of approval if you want. In addition to that, you can now select multiple things and approve or deny directly in mass editing. So that's something that will normally give you some time because doing it manually in this page could be a bit more annoying, potentially. It's not really a big deal. It's just a nice toy feature that we are dealing with. That's one of the pages, but it's not really the most important part. The important part of that PR is for the script that are already approved. So in that list, you have the possibility to see the previous approved script. In the previous version, when you approve a script, it's just the information you have. It's just all previous script approval and you have only one possibility to clear the approval. Nothing else. You are potentially a Jenkins expert and you know that T script are just stored in the file system. So if you want, you can just remove the different hash that are stored and it's good. You can manually and individually remove script. But as you know, you only have a hash and in case of a hash, you don't know what is the script behind. So it's just like playing a game, trying to remove things and oh, it's breaking my instance or not. With the new approach, you have no metadata by default because we still have just a hash. We cannot find magically the information behind that hash. But in the case, that hash is used by someone with the approval, so it will not block anything. But if you're using that information, for example, that system command to run the agent that you are seeing there, you can see the command because the hash is computed from the script and so with that information, we can collect, gather some metadata. In this case, I know that it's that command that is linked with that hash and so I can show you the information. If you want to know what is the content of that hash, it just expands the code, you see the content. You know also who was the requester in case we have that information, especially if it's something that was approved after the metadata introduction, you can see the approver when it was approved the last time. Also concerning the usage, if you are using that script, that code very often, you will see a number of usage that is very high and in contrary, if you are never using a script, for example, there are old script, legacy version that we are not using anymore and so the ideal thing is that you can just revoke the approver there. So you are reducing the potential attack vector in a sense, it's not really in terms of security but more about technical depth if you want. Also concerning that page, compared to the previous one, all the scripts are loaded dynamically so only when you request the page, you can have some user with hundreds or even thousands of entries that are already approved and with that information it's just impossible to have something like this. With all the script content being loaded dynamically, not dynamically, statically when you request the page, otherwise the approved page will take a long time to load. So to prevent that, you will just put some asynchronous loading of the script and so even if you have thousands of script, normally it will not take too long. In addition to that, you have a very small thing that I really like is that little tick in green that if you are an admin, configuring a job and that job contains some script, all the script you are writing are already approved because you are an admin like you don't have to approve your own script. It's automatic and so that tick is just saying it was a script that was written by an admin or someone with run script and so it's automatically approved. So that could be a nice difference for some of the script between something that was approved or something that was pre-approved. It could have some value for some user potentially. Concerning the other tab, the separation of the things that were done in the single page before it just for the moment separate into multiple tabs. We fought any rework on this part. It's just separation between tabs that was already a good thing but their content is not changed directly. And in addition to that, just a nice feature also you have knowledge about the number of things that are inside the different tabs instead of just having to browse to the different tab, you have the information directly in the title. And in addition, if the pending approval is empty and you are requesting the page that one, you are redirected to the first tab with something inside. So that could be really useful for you if you have something to approve or things like that. So I think I covered most of the things I wanted to discuss. If you have some questions, do not hesitate, please. It looks really great. Well, to be honest I have never really used this UI in my production instances. But yeah, I definitely know users who do use them. And for them it will be really handy especially since it's not just about pipeline, it's also about other engines like job base etc. So all of that can be approved then and it looks extremely handy now. Yeah, I use this interface regularly and absolutely adore what you've done, Vada. Thank you very much. Yes, and people chide me that I use this interface regularly, but I use it for testing in all sorts of ways and it's wonderful what you've done. Looking forward to seeing it. Perfect. So just in case the PR is ready for review if you want, the test are not written for the moment, not corrected because they are failing, especially I don't want to write the test before we approve what is the UI we want to have. So just in case you have also some screen shot with the explanation I just gave before and if you want to use a new instance, ideally on a backup of your instance in case it's breaking everything, it should not but just in case. So you can see what is happening, especially around the gathering of the metadata. It could be really nice. So I could grab a build of this from ci.jankins.io, where would I go get a prototype build of this? Bad question actually. Due to the test failing on that build, it's not possible directly. So I have to build it myself. Exactly. You have to use my branch and with that branch you can just maven and install and you have to think. Right. I know how to do HubPR checkout so I can do that. Great. Thank you, Vadek. I have a question. Can I manage script approvals from my mobile form? Asking for a friend. Honestly, I never tried but let's see if you reduce the page. As you can see, the table is especially not done for mobile. But that's always the problem when you have a page with a lot of information. Doing that in mobile is always a pain. And if we want to do something for mobile we can potentially reduce the number of columns, increasing the size of the row and things like that. Or in Jenkins Ior, we have several tables and there we applied magic layout which basically converts tables to rows when it gets narrow. I have no idea how it's implemented but it looks awesome. So anyway it's just an HKS. But for managers it should be really useful. Oh yeah, probably just one point that is the most important feature that I was a bit not sufficiently highlighted there. Here you have the Apple script. You can now revoke individually the script directly in the UI before using the file system. So just in case. Yeah, perfect. So I'm done with that in my demo. One maybe question. You improved the UI a lot. Are there any REST APIs or CLIs behind this UI which can be used for automation? Nothing planned at the moment. The API is just a regular thing from Jenkins. There is nothing specific. So if you have a token, you can call a different API method. And as do you have the different hash, you can just call the API with the correct hash and it's good. So it's an interesting question because actually in the current version everything is done with JavaScript API. I mean the JavaScript from Stepler. It's something that you cannot request using regular REST API but now I'm using a regular REST API so you can use them directly in your script potentially. It's just that you need to know the script, the hash of your script. Okay. Thank you. Okay. And we have one presentation left. So Mark and why and what will present her documentation and the highlights we had there. Thanks Oleg. Oh dear, where did my... I had my web browser on the screen. Seriously, instead I show everyone a blank screen. This one? No, just a minute please. Sorry. There we go. Okay. Yeah. So what I wanted to do was show some of the progress that we've made and we've had amazing progress in the last week of the Hackfest. The results are just sort of breathtaking. Okay. Here's one example. The Jenkins and Docker page has been re-vetted. It's thanks to Vlad. It's been much improved in terms of current videos instead of five-year-old videos. It's a lot better layout. Well done. Thank you. In terms of progress on issues, we started the week with about 80 or 90 open issues and 29 of them closed. We've closed 30 plus issues here, 25 plus issues here just with ongoing work there and you see a bunch of these issues that are still in work now. So we're so pleased with the results. Let's show some of the examples. For example, using local language is a new page added to the using Jenkins guide. Fingerprints. Aborting a build. Referencing a project by name. All these pages added to the benefit users of Jenkins as they have questions about how to use it. The remote access API. Great documentation here on different authentication techniques, different ways to use it using with Python. It's an excellent work done to gather information from the wiki and put it into Jenkins.io. Now in addition, the pipeline section got a major new addition thanks to Devin Nussbaum for migrating the pipeline CPS method mismatches page and bringing it up to date. So this was an excellent example of a place where we had good information but that was dated to the wiki and the process of transforming from wiki to Jenkins.io meant that we would revisit that and make sure that it was correct and more complete than it had been before. So thank you very much for that transition. Likewise, in managing Jenkins, we've got a bunch of new capabilities like instructions on the Jenkins command line interface, how to use it, adaptations and corrections to it. Authenticating scripted clients has just been added so that we've got examples for people who want to use Curl or WGED or Groovy or Perl or Java to authenticate to the Jenkins REST APIs. We've got progress now is showing dramatically and continues to increase on our plugin migration. So about five or six months ago plugin documentation began the process of transitioning to documentation as code so that plugin documentation was right inside the plugin GitHub repositories. Well, that progress now you see it here over 400 plugins have completed their migration to documentation as code with another over 80 with pull request pending their next release. So we're so delighted with that progress and encourage it to continue. This is giving us a much better layout through the static site plugins.jankens.io and making it easier to maintain plugins. We've got a project that tracks that progress. It's showing good results on automation and the work as we go through from each of the steps to extract the documentation out of whatever location it was put it into the GitHub repository all highlighted here and we can see visible progress likewise our administrator guide project in in GitHub is showing us progress and the user guide those are really the things that I wanted to show Oleg are there any questions relative to documentation not for me awesome progress but I guess we will spend the next week and maybe one week more to just review the pull request because we still have something like 30 or 40 staged so thanks to all contributors who submitted the pull request now yep it's our turn. Yeah it is absolutely sorry I hadn't turned on my video it's absolutely amazing the number of pull requests we've received and we are so grateful for those who've submitted those pull requests and glad we continue working with them to get them all the way merged so that they're helping Jenkins users speaking of that we have for Google season of dogs starting soon so somebody wants to keep working with us so there are good opportunities to do that thank you Oleg thank you too Oleg so maybe then out of demos does anybody want to show any last minute hook ones well I can show basically something that I had done couple years ago or one year ago but I would rather discuss it first with the quotation officer with Mark and with your leg before jumping to any demo just wanted to ask well I'm not sure if this forum is the right one for the best approach to running for instance Jenkins IOR and making this I usually use make inside my ID something like inside visual code but I notice there is Jenkins file inside that folder so does it make sense to use another Jenkins project and start this build process from another project using this Jenkins file or using something like you authored Oleg sometime ago Jenkins I'll run right here something like this like what is the best practice best approach in creating this Jenkins IOR site then demo time absolutely okay so anyway you have a few minutes so let's go we have this Jenkins IOR repository and if anyone wants to contribute we have contributing guidelines here contributing a dog and in these guidelines you can find steps which describe how to build and how to do common operations and this guide is actually all around make so there are two commands one is make prepare which prepares your repository for building so the build process itself is the curious and the demo is so you can use that and if you want to run to get Jenkins running I have no idea what is let's take a look I guess that was maybe a bit slow in the subsystem for Linux okay doesn't really matter let's just run it so yeah this is the common flow you run you use when you run a demo locally because make run basically packages your site prepares everything it's likely to be extremely slow right now because I should be running out of operating memory with zoom but maybe in a few minutes it will start up so it will basically provide you development copy you can edit the site for example in my case I use mostly visual studio code for development so why I use visual studio code because it's convenient before that I was using before that I was using cut down before that so you can basically take whatever you want which supports preview and highlighting yeah so now I have even less operating memory so you can develop the website here and you can dynamically deploy content so for example when you modify file layouts etc everything will be applied it's not a case for images and for some metadata for example here you can see that we have some metadata so this sometimes needs a restart of the website it mostly works but not always so if you talk about Jenkins file so we had some examples but Jenkins file is rather designed for continuous integration we had experiments with provisioning station and kisayo repositories but I'm not sure whether this code is still inside so yeah if you develop things locally it's better to run a make and everything is the correct so it can run on any machine if you use linux it's easier if you use macOS you just use docker for mark and everything will work pretty well if you use windows you can use docker for windows and like me you can see that I'm actually running on windows but with windows subsystem for linux with other magic I think we can develop this site using common make files common endpoints and it works pretty well yeah it's not that fast sometimes but yeah it's a problem of my laptop it's not a problem of the website so once it finishes I will just go to the website like Jenkins.io so let's assume that this site was built locally we will basically get it and we will be able to develop that with the guest provision on localhost 4242 so it's just in the development environment but right now it's not ready yeah well and I wholeheartedly support this particular technique makes it much easier to develop and to correct to readily see oh hey how does it look when presented on the page I can also change sizes of the web browser now very easily and say oh how does it look if I shrink this page just recently had some pages that had very wide examples on them and hadn't realized just how bad an impact a really wide example was on the overall layout of the page so helped a bunch to use make run to see if the page isn't as good looking as it should be let's fix the examples ok it looks like I won't be able to show it quickly so when I don't zoom it usually starts up in less than 1 million but yeah but like today still just everything can make and you have a lot to try to this flow yeah thanks thanks very much for sharing I just was wondering how to use Jenkins file and you clarify this that you are saying it is used for continuous integration which is generated after we do this full request thanks ok so any other comments or questions before we close down ah so so Runcia asked a question on how do you test a PR I like that question because it hides a lots of things in it oh leg are you interested in talking to that one or do we want to because you've got a way to test Jenkins PRs that's really elegant that I find just to be a beautiful thing and there are ways to test documentation PRs as well that I could talk to if that would help ok so I'm not sure what is my beautiful way but yeah by the way I stopped sharing how to finish the build almost immediately so yeah you can now see that my beautiful way of testing is it called the core PR tester or some such way oh yeah but it's for Jenkins core it's not for I was not talking about Jenkins IO I was just thinking that to test a PR to Jenkins core there's core PR tester and I think it's quite powerful to test a PR to Jenkins.io I could show a demo of that my question was about Jenkins IO testing it's perfect but I was wondering if we can have something as elegant as for Jenkins IO testing we do actually I can show it to you but it requires installing a specific command ok so if you want you can do that yeah basically we can add the same Jenkins IO PR tester it's not a problem at all personally I don't do that because it's just a few git commands to run with pull request running but yes in principle it would be an interesting topic to do so Mark if you want to show your flow it's fine in my case I just add additional remote I switch to the branch and then I get it running so nothing fascinating at all in my approach right so I'm going to share my screen and I'll show you mine which is doing exactly what Oleg does but it's doing with one command that I installed from a github repository so Oleg's technique is exactly the right technique let me share my screen and we'll show it to you ok so you should see a big ugly terminal emulator window and if I can make the text big enough to read is that readable to everybody yes it is ok so first magic is github.com provides a command line utility called hub hub you install it and it gives you additional capabilities it acts as an alias to command line git but will also give you additional capabilities like the one I love hub sync hub sync will bring down changes from your upstream repository merge them to your master branch all for you automatically so Oleg said mention that there are a couple of commands you use and get to do this hub sync encapsulates several of those commands so that was now if I look at my stat if I look at my branch list we should see that I'm on the master branch now if I wanted to evaluate a pull request let's say I wanted to evaluate let's pick one like maybe maybe this pull request right let's pick here we go number 3384 so if I click there this is the pull request and its number is right in the URL it's also there on over here so I'm going to say hub you are check out 3384 now all that does is connect the remote pull in the remote changes and give me a branch locally that I can use to do my work so I've now got the branch that matches my next step usually is oh I also want to see what it looks like with master so I merged from master and now I just say make run and it will now run a oh I've already got it running on another terminal how embarrassing okay let's go back here let's say make run and now it's going to start that web server and I can it's now running I'm not as capable as Oleg I run on a windows machine all the time but I'm not debugging and diagnosing on my windows machine and I'm not running Jenkins.io build so I have to use this tunnel that will let me see localhost 4242 on my windows computer even though my Jenkins.io is running on a website or on a Linux server near me so it is it is a delightful experience actually to sit in this kind of development mode because now I can I get all the benefit of the windows little utilities that let me change screen sizes to fit various things it's actually a fun experience to be able to develop this way so I can now change this one back to 1024 at all sorts of little utilities like that that just make the development experience better Runcia did that did that illustrate for you the how do you check out a PR and explore it yeah absolutely thank you I'm going to use help not for my own as well now now admittedly hub is just is just can't I right it's those things that hub did you could do with a get remote add I get so then I have to right and that's that was mine is oh you know what I know the sequence of commands but I too often forget them so I love the hub command hub is long term will be replaced by another command called GH but it's not been replaced yet and it's still very much being cared for and runs great thank you very much Mark thank you for the presentation thanks all so I guess we don't have any other questions yeah thanks again to those who contributed to the hugfest again we have final session on Monday it will be just a summary session if somebody wants to demo something on Monday let me know so we will organize something and have a great weekend nice weekend thanks all bye