 Really? All right, thanks everyone. This is the Jenkins LTS webinar for what's new in Jenkins 2.235.1. We're glad that you're joining us and delighted to be talking about things that are arriving or have arrived in Jenkins 2.235. Thanks very much for being with us. This is being recorded. This is a Jenkins online meetup. Our online meetups are community driven meetups. It can be any topic about Jenkins, case studies, success stories, other things of interest. We also host developer meetups. You can find those on meetup.com under Jenkins online meetup. And we are actively looking for speakers to present to the Jenkins online meetups. We'd love to have your topics. There's a process that's described there. We invite you to submit your topic proposals and we'll welcome you to come present for us and share with others in the community. During this particular session, we'd like to do questions and answers using the Zoom question and answer facility. That allows us to see the questions and allow some of the team hosting the webinar to help us answer the questions. It also gives us a chance to help you interactively here in the session. After the meetup, we encourage you to subscribe to the Jenkins user and developer mailing lists. In particular, they're great places to help each other. There's also the Jenkins user experience special interest group that has a get or chat where you can join in conversations about Jenkins user experience. At the conclusion of this, we'd invite you to complete the feedback form. We love to hear feedback on how we can improve, make better or strengthen the messages we're bringing to these webinars and to Jenkins users in the Jenkins community. Now, by way of reminder, the Jenkins project and all interactions within the Jenkins project are governed by the Jenkins code of conduct. We treat each other well. We like to treat one another with respect and with dignity, and we rely on you to do the same. This is a look at Jenkins LTS. We're going to look at new features and what things are described there. You'll see the URL at the bottom of your screen that points you to the Jenkins change log. It describes the current Jenkins release and past Jenkins releases and will highlight for you some of the features and capabilities that are being added in new Jenkins releases. In particular today, we're going to talk about improvements to the Jenkins plug-in manager, additional refinements to the Jenkins user interface. We're delighted to have Tim Jacome with us to talk to system read permission enhancements and ways that will help you get more value out of configuration as code and configuring your system as code. We're also looking forward to Mike Cirioli. Thank you for talking to us. We'll look forward to his presentation on overall manage. And then we'll have Oleg Nanashiv share with us on what's new in Jenkins core. What's next? What's new? I'm sorry. Thank you, Oleg. Yes, you're right. Oleg's correct. It's what's next in Jenkins core, not what's new. We're going to do what's new in the first four items on this agenda. Thanks, Oleg. That's fine. The first, first topic is the experience for users and administrators dealing with the plug-in manager. So we've enhanced the administration facilities. We've improved the notifications. First keyword, we recommend that you search rather than scroll through the Jenkins plug-in manager. In the top right-hand corner of this screenshot, you see Jenkins 2.222, the previous version. And what it shows is a long list of Jenkins plug-ins that are presented to the user when they look at the available tab. So here's my real demo. If you look at this scroll bar here, if I take away the search, that scroll bar is huge. There are a thousand plus plug-ins in that list, and it's almost unbearable to work with that. That's the old way of doing things. Now, if I look at the new way, it just presents me a field and I'm ready to search. So now it gets even better than this. So the presentation initially no longer shows me the daunting list of a thousand plug-ins. It instead invites me to search. So search don't scroll is the first idea. And then it gets better from better from there. So let's go to the next, which is that it's got a better search inside the search facility. So in the old way, here you see the old way, if I search for Git, okay, Git's a pretty important thing in the Jenkins infrastructure. I search for Git and it shows me the first thing in the list is GitHub authentication, Git lab authentication, Git colony. Those are not the first things I need when I'm thinking about how to solve, how to meet the needs of users with Git. So in the new way of doing things, if I search for Git, it shows me the most popular plugins first. And notice that it gives me hints with tagging and labels. It also gives me hints on version numbers and release states, all sorts of ways to make my experience better as a Jenkins administrator. So sorted by popularity, and we have better search. Now, when I say better search, it also means things like, let's, let's look at this one, for instance, if I wanted to do something with Git multi branch. I search for Git multi branch in the old user interface. Oh, it didn't find anything. Why not I know there's something about Git multi branch. Well, the new search actually does do. And there it is. There's the GitHub branch source. Here are more changes that could be involved in multi branch projects. So new search is just better. Now, multi word search. Yep, that's great as well. We love it. Now, in addition, there are now hints built into the, the plugin manager when looking at it that show me labels and indicators if there's a security fix involved in something I'm doing. It gives me a reminder about the plugin release date. So I can hit Oh wow this plugin was released just very recently. I may need to think more carefully about it or oh this plugin was last release nine years ago. Yeah, should I be using that plugin release states can help you decide which plugins you should use in which plugins you should not. It also has hints on plugins that are up for adoption. So if a plugin maintainer has decided to step away from the plugin they can market for adoption, and you now as an administrator will get to see oh this plugin is up for adoption. It's a good way for you to think more clearly and more cleanly about which plugins should should you use and which plugins you might just say I'm not ready to use that one. So the updates also are easier on you so I'm going to show updates in the old world. Here's updates. My Jenkins here has several plugins that need to be updated and it tells me hey here they are and here's the version number, what's installed and what I'll get. Well the new Jenkins user, the new Jenkins plugins plugin manager provides, not just. The new version but when was it released what version is currently installed and I get the benefit of all the hints here of labels telling me which things are involved, which tags are associated with these capabilities so oh I want to look at only the plugins being updated which are API plugins. There they are. Easy clicking a label gives me access to all the things that match the label in that view. All sorts of new hints and new capabilities to make your experience better and simpler as you work with the plugin manager. Now I did see a question here in the in the online that asks is there a plan to hide plugin versions that aren't compatible with running Jenkins version will plug in versions which require a newer version of Jenkins. By default won't be displayed as available anyway. I actually had a good question recently on that where someone wanted to use the dark themes plugin and their desire to use the dark themes plugin they were running a version that didn't yet wasn't yet supported by dark themes so they had to upgrade to a newer Jenkins version. Just to add more information to this answer Jenkins Update Center. So if you use Update Center provided by the Jenkins project it provides details for weekly releases and for five recent LTS releases. So for weekly releases you will always see the recent plugins for LTS releases you will see only plugins and plugin versions which are compatible with your LTS baseline. Unless your LTS baseline is too old. If you use custom update centers then it's up to administrator of this custom update center to properly expose a plugin information. We provide tools for that but ultimately it's up to maintainers to properly define plugin sets there. Thank you. Thanks Oleg. So now in addition to plugin management experience improvements there are also improvements in the overall user experience for Jenkins users. The Jenkins user experience special interest group is making steady and very interesting progress on improving the Jenkins user experience. As one item auto refresh used to be available in Jenkins as a way to cause the browser to force a complete reload of that page. That complete reload of the page tends to be a heavy weight operation. And it could cause performance problems. We've taken away that enable auto refresh. It was causing usability problems for users who they would have any auto refresh enabled and open a form and be dismayed when the form would be refreshed away. If you need something like auto refresh that usually is an indicator that we need to find a way to automatically update the content inside the Jenkins page. That you're you're viewing rather than requiring that you refresh the page and in the short term, you could use it a browser extension that will do the auto reload for you. Now, in addition, Jenkins two dot 235 has added tiled, tiled segments into the system configuration to manage Jenkins page. So, whereas you see on the top right here, configure system configure global security we're all a long linear list of items, it's now been tiled, and the tiling adapts to the width of your screen. These screens may get two columns, wide screens may get four or more. It's a much easier way to view and find those capabilities and gives you a simpler way to navigate when you're using the manage Jenkins page. In addition, the, the core layout of Jenkins has been improved by using system fonts more frequently. This particular screenshot may be a little difficult to see the difference it's a somewhat subtle difference in the top right hand side. Things are a little closer together and the fonts aren't quite as Chris. The bottom left, what you see is Jenkins two dot 235 with a little more spacing and a little clearer fonts because of this, this change to use system fonts, rather than the fonts that we're using previously. We're grateful to the ux sig they're making great progress on the topic and looking forward to letting you know more about it during our what's next segment that will come up at the end of our webinar. Next piece, Tim Jacob and read only Jenkins configuration. Tim, I'm going to go ahead and stop would you want me to hold the slides here or what would you prefer. It depends on if you want me to show a quick example or I would love to have an example included if you're if you're willing to do the example you tell me when you would like it and I'll give you control. Yep. Yeah, I'll tell you when when I'm ready. But if you just go through on to the next slide. So read only Jenkins has been a topic for quite a long time and Jenkins think the first issue about it was credit about six years ago. The driver for me for introducing this was to complete the story for configuration as code users so that users of that plug in wouldn't would be able to still view all the system configuration and help contribute to it without being tempted to make changes in the UI. So there's been a new commission introduced the overall system read, which allows you to now have access to the system configuration, but no access to change it. Most of the so everything, everything that seemed interesting and Jenkins core is available. You can see manage Jenkins page the tool configuration plugins configuration as code. So not everything's there, but if there's something that you do want that isn't currently available because a epic that you can create issues in as part of this. So a long time ago about 10 years ago now the extended read permission was created. And as part of this we updated that to use some of the new engine that was built to make the pages actually look read only to improve the user experience. And we found an agent extended read permission was created a few years ago as well and we fixed it up to actually work properly. And so now you can also see agent configuration and cloud configuration if you have the right permissions to. So just give a quick demo on one of the Jenkins project. So it's running that has this has this going. If I share my screen. So this is the Jenkins project in for CI. I just have the. I just have read access to this. So if you see here this is just me with read and manage and system read. I go here. I can see the build executors. So the master configuration is not much there. What's interesting is that I can go to the manage Jenkins page. I can see how it's been configured. I can go to the configuration as code and I can view the configuration or download it. And I can also go to the configure system page. So that allows you to enable your users to see how it's been configured. And then they can suggest changes to it via the code. And even if you don't want to at least they know how it's configured. So it's it's giving more information to the two users. So you see here and the other thing is that it looks read only. So as much as possible we've removed buttons. We've changed it to change the behavior to show that you can't change them. These checkboxes are disabled. Inputs have been removed in general. Where possible they've been disabled. Not everything. So everything that's controlled in Jenkins core has been changed. But a lot of functionality is in plugins and it depends on whether they use the core components. Or whether they're doing their own thing. And if they're doing their own thing, there'll be some work needed to update the plugin. But in general it works really well. And I think it's quite a few people using it. We just go back to the presentation mark. Sure. I've got to find my share button. Yeah. So this was released as an initial beta in 2.222 LCS. It was very little functionality. I think you could just see the managed system page and the system info. Between 2.222 and 2.235. We can please those. Most, pretty much all the planned work, especially in Jenkins core. There's still UX improvements and some plugins that need support. But the core work has all been completed. And to use it, you just need to install the extended read permission plugin. And then it will automatically be activated. And then you need to give your users the permissions. So in whatever permission plugin you use, if it's matrix or author, roles, just need to add the required permissions, the system read, extended read, and well, agent extended read and job extended read. I think that's all from me. Unless anyone else wants to add anything. So, so that this really is focused then on letting me define my configuration as code still show to my users what, what they, the settings are. So they are not kept in the dark about the settings. They're not hidden from them. But then the idea is they will submit pull requests to my get repository that describes my, my configuration in the YAML file. That's, that's. Yeah. Either that or they know who to talk to. They know, they know how it's configured. And then they can talk to the person who is able to, and they can also see who has access to do it as well. So the security configuration is there and you can see, and they can see who has access to do what. So they, they know who to talk to as well as another benefit. Excellent. Thanks very much, Tim. Thank you. Thank you. All right. I think we're ready to go on to our next topic then. We're going to talk a little bit more about what we're going to talk about. Overall manage permission. So system read permission was one enhancement in two dot 235. Overall manages another. Mike Ciriola is going to introduce this one to us. Mike, go ahead. Thanks, Mark. So kind of in a similar motivation to, to Tim's. Overall read or system read. Right now in. To you pretty much was an all or nothing proposition in terms of administering. Or allowing someone to administer your Jenkins instance. You can give them overall administer. Or not. And they either can do everything or nothing. So that doesn't really lend itself well to being able to. Delegate some things that. Probably matter more to day to day. developers and users of a Jenkins instance while still being sure that things like security isn't being compromised, you know dangerous plugins aren't being installed, or you know have allowing you some control over over the important parts. And so that was a motivation for introducing the new permission of overall manage. It's less than it's less than administer but it still lets you manage a number of things. Right now most of it is the working core has been done since 2.222. There are a number of plugins that have been updated and released or in the process of working their way through being released that take advantage of this. So right now you can actually like go to the next slide or actually I can just I have a little demo. It's sometimes a little easier just to show what the difference is. Yeah I like demos. Demonstration is great. If you're willing to just share your screen and show us your demo that would be great. You guys see Firefox? We do. I lost my view of the screen. So right now I've got, right here I have a browser with three different users logged in. This first one, this is the normal I'm a full Jenkins administrator view and you can see you see everything you would expect to see here. Now if you go into global security using matrix auth, you can see there is a new permission here in the overall category called manage and so if you grant a user or group that permission along with the overall repermission that will allow them to first like actually see the managed Jenkins link here on their left-hand nav because normally for a non administrator user you don't have access to any of that and so this link isn't shown. But you can see here there's a subset of things compared to the full I can administer everything that are available to a user. And then within a configure system you can actually still you can manage plugin configurations that show up here or really anywhere within the UI. So this is not super exciting. I don't think many people want to go in and change the system message like every day and the real power for this will come as more and more plugins start to adopt this new permission and it's relatively simple just to do you basically just change permission checks from currently being Jenkins administer to Jenkins manage in your plugin where you feel it's appropriate and safe. You can see here as a managed user I don't have access to configure the system security for instance. So there's no worry that if I delegate some administration to a user that they're going to go in and you know open everything up to anybody who wants to do something malicious. Another interesting thing is that this permission also works well with the overall the system repermission and so this is a third user I have who are granted both the overall manage and system read to. You can see for this user now they can see things that you would be able to see as a user with the system repermission so I can see the security but I can't change it. And even within configure system for instance I now can see quite a bit more but I still am only able to make changes you know to the parts that actually have been granted the ability to be managed through the overall manage permission. And this is an opt-in similar to system read. There's a plugin called enable overall manage permission that's available by default. You just simply install that plugin and you will see the new permissions available if you're using a simpler matrix auth. That's pretty much what I have to show. Thanks Mike. Thanks very much. So for me that configure global security thing is the major one. It's that I can delegate permissions to do many of the management tasks without allowing them to alter the security definition. I saw shutdown was another one that there were some other things in addition it's not just security. So you can as a manager you can just shut a Jenkins instance down but that so the sort of the guiding principle was in general allow a user would manage to do something as long as that thing doesn't have lead to a potential escalation of privileges. So run scripts is right out the window anything with configuring security. But beyond that we don't right now there's not a in more fine-grained way to manage permissions in Jenkins where I can pick and choose very specifically what a user or a group is allowed to do. Thank you. Thanks very much. Much appreciated. So I think that concluded the piece that you wanted overall manage. You okay if I take back screen sharing? I am. All right. Thanks a lot for the presentation Mike. If you have any questions to presenters please use Zomkone and represent new features many of them are in preview and any feedback from you will be appreciated because it will help us to improve them and any adoption and additional insights would be appreciated. Thanks Oleg. Yes absolutely. So for reference you can refer to the Jenkins changelog to see more about what's in Jenkins 2.235. Upgrade guidelines are also provided. These are both common features that we do for each new LTS. We invite you to read them, refer to them, use them to your benefit. Thanks very much for your interest in Jenkins 2.235. You can find these particular slides at that URL. We'll also post a link to those slides into the meetup afterwards. We've now got what's next and what's coming. So Oleg would you like to take over? Do you want me to give you screen control Oleg's or do you want to just? I would rather prefer to screen share. Okay great. Okay do you see my screen? Yes. Okay let's talk about what's going on in the Jenkins project and what's we are going to deliver in the next LTS baselines hopefully in September. Some features may take longer but anyway we would like to share some insights of what's happening in the project. One important thing that we are currently working on the public Jenkins roadmap and if you interested to know more about what's in the project you can refer to Jenkins.io slash project slash roadmap and here you can find a lot of stories which are currently in preview or in ongoing development. So today we have all of the presented some stories for example managed permissions, system read permissions, you can find them here and yeah there is a lot more in progress. I will just share some insights about stories which are related to the Jenkins core or to infrastructure connected to the Jenkins core. So it's just a subset of what we are planning to do. One important topic is dark theme and yeah maybe you would like to speak a bit about it. Yeah sure. So the dark theme is something that was introduced during the UI UX hackathon. We have added support for CSS variables to Jenkins to enable easier theming and to make it less likely to break when Jenkins core changes. So now it's using a CSS API rather than targeting individual marker so it should be a lot safer. It's been released as a plugin that you can just install. There's also instructions on how to configure it with simple theme plugin if you want to do that instead. It requires at least 2.239 so the weekly versions currently although the latest will be the best as almost every weekly there's been changes for dark theme. So the most recent will have the best experience. Yeah it's a plugin hosted in the Jenkins GitHub organization and you can raise issues on there if you find any compatibility issues or improvements that you think can be made. But it's going quite well I think. It's quite usable and I'm using it every day. I know others are as well. I'm still yet to upgrade my instances to the recent Jenkins weekly but I confirm that it looks pretty awesome and good support for many major features including console logs, pipeline stage view and many other components. So now the theme looks really well. If you are using Jenkins weekly you can already upgrade that. And one notable change which Tim didn't mention that this dark theme it's also using another plugin on the hood. There is theme manager plugin. So it allows not only to manage themes on a global level like you can do with a simple theme plugin now but you can also manage themes as a user if your Jenkins administrator allows that. So it's also an interesting feature to explore and it's available in the current weekly releases and it should become available in LCS in September. So it looks pretty well. There are some open topics and compatibility issues. So if you evaluate it, please report any issues you hit. So for example here you can see that there are some reports from contributors who already tried it out and discovered some issues here and there. For example GitHub uses dark icon. So you can see GitHub logo for example on the label screen or there are some other reports for example about statistics is too bright. So if you see glitches like that please report that because during UIUX hot press we already applied a lot of patches and we keep working on that. So any feedback from our doctors will be appreciated. I'm impressed with the ways that this can be evaluated and in the dark theme plugin documentation you had provided ways that people can evaluate very rapidly, right? There are all sorts of suggestions of hey you do this and do this to help with the evaluation. That's great. Yeah and you can also, there's two modes in dark theme as well. You can either force it for everyone or based on system settings and then also users can opt in or out as well. So it's quite configurable. We run it with the operating system settings. So only the people with dark mode enabled at the OS level get it and they can also opt out if they don't want it or if there's some compatibility issue that means they don't want to use it. But so far feedback from users that I support they're all using it. I don't know if anyone has turned it off. I should check that. But anyway it's a great improvement and later we can add more themes to theme manager for example new two theme and other popular themes so they could be edited using the same engine and there was a lot of groundwork. So yeah I would like to thank all the contributors. We actually have a list of contributors here but I think that we need to update this list a bit. But yeah this is a list of those who contributed during the UI UX hackfest and now I suppose twice more contributors so even more. So thanks to everybody who helped push this project forward. Anything else? I see there is quite a number of questions but I'm not sure whether anything is related to the dark theme. I didn't see any specific to dark theme. Okay so yeah we will handle the rest later. Another important change we are working on is improvement of configuration UI. So if you work with current Jenkins configurations yeah you know that they are really long at the same time we use stable layout so you kind of easily configure Jenkins on narrow screens. If you try opening it on mobile it will be even worse. It's hard to maybe get through multi-level configurations and as a user experience special interest group is working on improving accessibility of the Jenkins project. It's one of other projects on our roadmap. Yeah I'll keep showing it today. If I find it of course. Okay so yeah one of the projects here is actually improving accessibility and we did a significant progress there during the hackfest and later. And the configuration UI to tables is one of the stage full request. So it's not available in Jenkins weekly now but hopefully we will be able to make it available soon. And it improves navigation a lot. So if you're interested in that take a look at the ticket I linked here. There are testing guidelines available right inside the ticket. There is also a quick start demo. You can just run it in Docker or you can build it on your own. Actually it would be a great help for us because this change may input other plugin configurations but still we want to deliver that because it greatly improves configuration pages. And it's not just a system configuration page it's also job configurations and for other forms like let's say build parameters all of them are actually in scope for this change. I've been I was initially skeptical actually of this change and I've fallen in love with what it does for me. It makes things much more usable from the user interface. I'm less frequently having to scroll horizontally left to right even on my wide monitor because of this kind of change. So thanks very much to the people who are willing to launch this and for all the work that's gone in thus far to get there. Yeah so the most of credits go to Josh Sorev, Felix and Tim and to many other contributors who report issues because it's a wide change so it requires a lot of testing to move it forward. Okay other important thing which is coming in Jenkins core is improvement of external fingerprint storage. We have Sumisarin who is a JSOP assignment 20 student so he is working on providing a new backend for fingerprint storage. If you're not familiar with what fingerprints do they basically allow tracing usage of various items in Jenkins most likely artifacts credentials or docket images or containers when you develop when you use them so you can easily see the entire delivery pipeline for particular artifact or where it was used in other jobs if you use various job chains and currently this engine uses file system storage on Jenkins home so basically you have to manage backups on your own also you don't have so much opportunities to query the data and to process that so as a part of the project we want to move it as external storage as many other items like logs, configurations etc and it also allows to improve availability and traceability of Jenkins and in the future we also want to support multi-master tracing of artifacts or images so if you use multiple Jenkins servers in your delivery pipelines you will also be able to use these two in order to trace usages of these artifacts. So right now this feature is in preview code changes are integrated there is a plug-in with a reference implementation for Redis and it should be landed that this day before this meeting we were discussing the release of this plug-in and the ability that it's released so if you want to try it out just do so and next week we will have a more detailed demo about this project. Okay so what's next? We're also working on terminology cleanup so in 2016 we renamed Slaves to Agents but still there is a lot of leftovers here and there so we are working on cleaning them up including web UI, documentation, liquidizations, we also do planning for Jenkins core API cleanup and again we invite contributors to participate in this effort because there is a lot of changes here and there and sometimes you don't even need anything except a GitHub web interface in order to deliver a change so if you're looking for items where you can contribute it could be one of the topics and again you can just open this change and see what's inside. So here for example you open this issue and here you can see you come up friendly issues so just run a query and basically half of the items in this query can be easily fixed without any experience of Jenkins contribution so for example we clean up a lot of that but items like that can be easily cleaned up. Before that there were a lot of examples just in the beginning which were not involved in KPIs but we all simply cleaned them up so a lot more to do. We also discuss other terminology updates so for example we had a governance meeting last week we decided that we want to remain master. We will be actually launching a public vote about a new name so if you're interested there is a developer manifest right where you can find more details and also for white leaves, black leaves and potentially other terminology we are working on suggest replacements and we are well aware about this topic and we would like to change this terminology in the future. Another important change in the project is the way to distributions. If you use Jenkins weekly you have already seen a new Windows installer created by Alex Earl. It doesn't include bundled JDK, it includes water improvements for user management and many advanced options. We plan to make this Instagram available in the LCS releases soon hopefully in the coming months. We also work on Docker images. We plan to integrate all images to adopt OpenJDK. Most of them are based on OpenJDK and we want to extend support for platforms so we want to provide official images for ARM64, for IBM S390, PowerPC for both Java 8 and Java 11 and it will help to run Jenkins on more platforms. We also plan to change assigning keys so most likely in the next releases you will need to modify keys if you use for example distributions for like just FPM or up to you will need to update keys. Once we do that you will see guidelines how to do that in update guidelines. Another important thing is Jenkins infrastructure because when you run Jenkins you actually use the infrastructure and right now there is a lot of contributions here and there we should improve user experience. One of notable changes today is for example on the plugin side so if you go to the plugins Jenkins.io you can find that there are already some changes on the plugin side. So for example when we navigate here you can see that now you can find history of releases or list of reported issues right inside the web interface. There are still patches to be done for example support for GitHub issues or support for change.locmd files but for many plugins you can already get these benefits and if you use plugin manager mark demonstrated you can basically get to this web interface in one click now. So if you investigate what changed in plugins etc you can quickly get this data and hopefully we will make it available in Jenkins plugin soon as well. Another important change is categorization and search for plugins so you can see that plugins have labels and yeah maybe API plugin is not that informative but there are other labels for example if you're interested in plugins for Kubernetes you can just search for Kubernetes there and you can find some plugins you can also find categories on the left so right now there is a lot of improvements to be done there but we started doing the investment in order to provide better search and to provide the better categorization of plugin by default and once it's done on the plugin side we will be also moving to the Jenkins core so that it improves user experience here as well. Related change to the plugin side is update center improvements because yeah plugin side as well as plugin manager and Jenkins core they receive data from update centers and there are many improvements there for example Daniel Beck has created but flexible update center so now you cannot actually you can access available plugins for a number of recent weekly and LCS releases so when I was answering previous question I was exactly correct so now for recent weekly you can also get a list of compatible plugins and there is also more metadata plant to become available for plugin manager for plugin side for example direct links to change logs and other such improvements here and there so we will keep improving that. Another change which is important to Jenkins user is better mirror and trustworthy so if you use Jenkins now you may be able to hit the issues with plugin not being available it's not a big deal in Jenkins web interface because you can just re-download it becomes a bigger problem for example if you built a Docker image with plugins 60 but the availability of a single plugin if it fails after several retries basically it fails to be built so it's one of the symptoms of current state of mirror infrastructure we plan to expand it we plan to add more mirrors in order to speed up downloads and make the entire infrastructure more stable so it just heads up and hopefully it will happen soon. Another thing which is rather focused on Jenkins developers we are working on new release automation it's already available for weekly releases so we ship weekly releases from new infrastructure and if you use weeklys you have already had top-dead for example keys for debing packages etc but the same change is coming for LCS so that for LCS we will be using infrastructure we will be able to deliver LCS releases more reliably without the delays and again this is the change we are going to have by the next LCS baseline so stay tuned there is a lot of changes here and there and if you interested this is a great opportunity to contribute you can test the existing stories like configuration tables to deep immigration or read on the Jenkins configuration you can also contribute to documentation to quote there is a lot of various newcomer friendly issues you could address and of course if you want to share your story to present you we also welcome you to do that so here this is just our landing for the information for example if you want to quote or if you want to improve documentation you just go there and you can find references including information for newcomers different queries where you can find issues you could work on and yeah Jenkins project is driven by contributors and we invite anyone to join and to improve the project together and actually that's it from me so thanks for your time I hope it provides insights of what's going on again it's just a slice it's just for the Jenkins core there is a lot of other stories and plugins like pipelines, script security and other important changes so you can refer to this roadmap in order to find a full list of major initiatives happening to the project not a full list of all changes but at least for major initiative we were able to capture here okay that's it from me we get any questions there are some exactly thank you there are some questions that had arrived one was sort of peripheral but I like the question and I think we should hoist it how long is support for LTS and what is the the life cycle of long-term support releases okay let me show the answer so if you go to the Jenkins download page actually we have a special page your Jenkins download LTS if you go here you can find more information about our release cycle so yeah LTS it's a historical name long-term support personally I call them stable releases every 12 weeks we select a new baseline we stabilize that is baseline where backport patches and after that we do three backport releases and after that we choose another TS baseline stable baseline again with port changes and make it available so how long the support for LTS technically it's three months at the moment yeah there will be a lot of discussions in the community about having real LTS let's say one year but we do not do it at the moment yeah so the in this case that the crucial piece of information for me is then that I need to I need to plan to upgrade about every three months to get the most recent Jenkins release that's stable tested and then within that there will be roughly monthly releases that will give me updates to that stable baseline in principle yes in practice you also need to keep in mind security releases because yes stable releases so they improve provide improvements when we update to the new baseline when you update to a dot version you get some fixes but sometimes these fixes also include secure vulnerability fixes if you run Jenkins in isolated environment probably it's not a problem but if you Jenkins instance faces public you should really follow security updates and here for example you can find our advisors archive and you can see that the last security release for the Jenkins core was actually in March and before that it was in January so if the security is a concern for your instance please subscribe to our advisories or to RSS feed and yeah we sent pre-announcements about releases but this is the time when you really should plan upgrade upgrading for other releases is basically your choice you can use change log Marcus already presented this thing so here you can find all the information about what changes in the releases and for example here we released it one week ago you can check what are the major bug fixes available being compared to previous versions what are the major features basically what we presented today and then you can make a decision whether you want to upgrade or not so please refer to these change logs to make a decision if it's not the security release thank you now we had another question this was I think a little more peripheral related Oleg on further development of the subversion plug-in this may be a chance to talk about plug-in development in general okay let's spend a few minutes on that so yes a version plug-in yeah let's take a look at the current state so you can see here that this plug-in is up for adoption again it's a recent improvement in Jenkins code and plug-in site so now it shows this flag and what it means that basically this plug-in is not actively maintained at the moment and we are looking for contributors there is a process describing how to contribute how to step up and become a maintainer of plug-in and so if you're interested in a new subversion basically the best way to get it is to contribute in some cases an exceptional cases for example here five months ago there was a release let's take a look what was this release and this was a security advisory so basically Jenkins security team cut release because they were security vulnerability and they made a decision to release it because you can see that it's still users being used by hundreds of thousands users because other plugins depend on that and it used to be bundled in the Jenkins code maybe it's because of lotion maybe of something else I'm not sure but almost every instance has a setup and yeah that's why it was released but generally it needs somebody if you have a bug fix you would like to see then the best way is to just step up and offer help because that's how Jenkins communicates well and and for me at least becoming a plug-in maintainer I initially had the flawed perception that I needed to be some sort of a brilliant expert on some topic and rather what was needed in my case to become a plug-in maintainer was willingness to work on it and willingness to learn and develop that there were plenty of people willing to offer me coaching to say no that's not quite what you want to do you should do this so so don't be shy about offering to help with plug-in maintenance because you feel inadequate or you feel like you're not the guru of everything when I started developing I think my first plugins actually I wasn't expert in Java in any means and probably I'm not an expert even now but looking at my former code still anyone is welcome to join and I wouldn't expect major changes in the subversion plugin unless there is an active maintainer there it might be not an ideal question but yeah this is a the state of our face in the project so yeah obviously subversion is not that actually used as it used to be 10 years ago many maintainers moved on if somebody is interested you're always welcome to join and thank you now there's another question maybe this is when we hoist to Tim on logging in for both verbosity in configuration is code and I was assuming that the answer there is that hey we love to have bug reports we love to have enhancement requests and if you're finding something hard to read submit a bug report or submit an enhanced request or submit a proposed change to the code Tim anything more you want to add on that no yeah just if there's issues just submit it there has been fixes done in the past to improve it there were fixes done to add all the attributes and try and improve it so that all the information you need is there but if it's not readable then just send examples and credit and harassment quest or a poor quest we'd love to improve it thanks and then then there's one last question oh actually yes thanks Oleg your pointer to the feedback form for the meetup there's a question relative to a plain Jenkins container that I think has been answered separately on the list did you want to address that at all Oleg or should we just look at the form yeah I had a look at the download page as a way to get a plain Jenkins word without a Winston container so Jenkins itself it supports yep sorry I'm scrunching the feedback form but if if you interest please provide your feedback so if you go to Jenkins I your download page here you can find multiple options so with different distributions these distributions yes they come with Winston JT embedded so we use JT as an embedded web container but if you want to deploy Jenkins in other containers for example you know in Liberty in Apache Tom Carter or whatever you can just download the word package and deploy it in a proper environment so it's possible you just download it you configure your web container to use this word file similarly to any kinds of other word files and you get it running in such case yes they will be Winston technically in embedded in Jenkins but it the web container won't be using that you will be using external web container and you can also connect the authentication and in some cases authorization to external web container so that you don't have to manage it on your own I think yeah personally I don't really recommend that but if you want to do that you totally can do that now back to the feedback form so that was that was a crucial place where we would really like users participants in these webinars to give us feedback and help us understand what things will help them more what will help them less yep and if you spend a few minutes to fill in this form it will be much appreciated later after the meetup once we have video we will be sharing all the materials with participants and we will also share a link to this feedback form but now you can find it in the chat okay so basically we are running out of time are there any last-minute questions or any topics panelists would like to bring up thanks very much to everyone for taking the time thank you very much for joining with us and thanks to our panelists Tim Oleg Mike thank you very much thanks all okay I will