 and this is a Jenkins developers online meetup on dependabot for Jenkins plug-in development with Oleg Nanashiv. Oleg? Yeah. Hi everyone. Thanks for coming. So just for those who do not know what our developer meetups are about, actually there are many people because we are just starting, it's our second meetup. So the idea is to have regular meetups for people who contribute to Jenkins who want to know more about development for Jenkins, mostly for plug-in development, and we want to talk about developer tools, any kind of best practices. So it's not just about Jenkins. We will be covering common tools, which other software engineers may also use. The idea is to have informal discussions, mostly to focus on show and tell and demos. So we have some slide decks, but we can deviate from them a lot and we invite everybody to participate in the discussion. So we all, yeah, messed up the slides of course. And if you're interested to speak at the developer meetup, if you want to present your tool or whatever, just join advocacy and outreach Gitter channel and we will be able to discuss topics there. So yeah, my name is Oleg Nanashiv. I'm one of Jenkins Core maintainers. I've been with the project since 2012 and I work a lot on different development tools, including plug-in POM, plug-in compatibility tester and the dependable which we discussed today. I actually started doing it in June this year to help other plug-in maintainers to spend less time on routine tasks and to focus more on real development. You also have Mark way on the call. Mark, would you like to introduce yourself? Yeah, so I maintain the get plug-in. I'm the happy beneficiary of many of the initiatives to provide improved tooling to people who do plug-in development. So I'm the very grateful beneficiary of Oleg's efforts and others. Thanks very much. Thank you. Okay, today we focus on dependable. So dependable is one of the tools which allows to automate dependency management for GitHub repositories. If you use Bitbucket or other source code systems that are equivalent bots, but today we focus only on GitHub and only on a single bot. There are other solutions available. If you're interested to get these slides, the Bitly link is shared in the Zoom chat and it's also on the slide deck. So you can just open them in real time unless your permissions are fine. And we will focus on dependable. I will provide a quick introduction and then I'll show how we use it in Jenkins and provide some hints how to properly use it in Jenkins. That's the idea. If you have any questions, again, Zoom chat. Mark will interrupt me if needed. And the results are offline for each channel, platform seek. So historically it was platform special interest group which started using dependency management tools. And if you want to ask any questions, just go there and ask. So the question to you, what's going on between Maven and PM or PM and actually almost any other system? Who does know the answer? You have seen these slides before? Okay. So yeah, actually it's dependency help because whatever dependency management system you use, eventually you end up in a situation when you have hundreds of dependencies coming from different locations, you have transitive dependencies. At some point it's just difficult to understand what you use and you may get various kinds of conflicts. And eventually your Linux system may stop working or your Jenkins plugin may end up with binary conflicts and fail to start up using the Jenkins instance sometimes. So obviously we want to prevent that. In Jenkins, we actually have many kinds of dependencies. If we talk about a plugin ecosystem and Jenkins core, so it's a common excuse for development. Jenkins core may include a number of libraries which are exposed to consumers as API. So Jenkins right now doesn't have fast isolation in between plugins and between libraries. Plugins depend on Jenkins core. Plugins may also depend on each other and plugins may depend on libraries. In so much cases, we have multiple plugins depending on a single library. For example, it may be Jackson, it may be Snakey Amal or the commonly used dependencies which are quite popular and plugins may require them. And we also have some cases where plugins and Jenkins core depend on a single library and sometimes plugins require a higher version than Jenkins core. It's technically possible, though you won't be touching these parts because it's definitely not recommended. Why did we start working on the dependency management in Jenkins? You may have heard about Java 11 support project in Jenkins. And one of the things we had to do there is to update many dependencies because we needed all libraries to be compatible with Java when we needed to update development tools. And as you may imagine when you do bulk updates, things start falling apart. Sometimes it's difficult to record what happens. And for me, the main takeaway from that project was that actually we should have been doing dependency management not in bulk when we need something but actually gradually during the project lifetime. So we would be picking recent dependencies, assuming that we have good CI, we would be able to discover issues, but we would be able to provide recent versions to API consumers and to our users because libraries also include bug fixes, sometimes they include security fixes and generally we want to stay on top of it. In Jenkins, the most popular tool chain is Java and Maven. There are some plugins which use Java and Reddle, but Maven is the most common tool. And in Maven, there are plugins which allow to actually display available updates and update them. So for example, there is a common Maven command, but if you just run it, you would be running it manually. And since we are talking about automation server project, it's definitely not something we want to do. We want to automate the dependencies and to automate the dependencies, there are many tools. The most popular ones are Dependabot, which we are discussing today. There is also Renovate, which is more focused on front-end projects and GreenKeeper. All of them are available as GitHub applications and they integrate with Jenkins GitHub stack well. But again, today our focus is Dependabot. Dependabot may be the most compelling tool for GitHub, because GitHub has acquired the Dependabot last spring. So now Dependabot is the fact that part of GitHub is available for free, for private source, repository, obviously for open source as well. And it gets a lot of adoption. You can use Dependabot in two ways. One is CLI2. So you can just run it externally. But what you can actually use with GitHub is GitHub application. So it's a tool which runs in source and integrates with your depositories and with common GitHub tools. So you don't need to stop everything, anything, you just click your checkboxes and get it running. And this is what we use. So the idea of Dependabot is to just submit pull requests with dependencies. Probably I could just show it live. Do we have any questions so far? I don't see any in the chat. And I haven't seen any come in through platform sync. I think we're okay. Okay. So yeah, how it looks like in practice, Dependabot submits separate requests for which dependencies. So here you can see that there is a lot of pull requests being submitted by Dependabot. For example, a recent update for JUnit. There are some updates for Maven plugins like JMaven plus frontend Maven plugin. We also receive updates for test libraries. This is plugin POM. It's a base POM for plugin development. So the most of that are about development tools. And here if you go to each of these pull requests, we can see that there some additional information provided. So for example here. So what do we have here? There is a pull request. Again, it's submitted automatically. And here you can see that there is some change log. Well, this time it wasn't parsed correctly, but at least we have a link. Which points to the frontend where you can see the changes available there. Also you can get a list of commits, which you want to enter this release. And Dependabot tries to do some big data. There is a base here. And it shows compatibility stats across multiple open source projects. Because when many projects use repositories, you can collect some additional statistics. So Oleg, on that compatibility stats, I've seen somewhere the compatibility score was 80% roughly. Is that a concern for me? Should I be worried if the compatibility isn't 100% it's something to keep in mind. So let's try to find something. Okay, Gmaven plus, yep, 80% you were mentioning. And here by the way, change logs are visualized properly in the web interface, which helps maintainers. So let's take a look at this 80%. And here, basically, you can get a reference to the pull request, which fails. So here's just one pull request. So we can assume that there were five builds recently, which you know, of these updates. And here we can see why it fails. So it fails on Travis. So we can just go and investigate. I have no idea what is this report about. But yeah, theoretically, as a maintainer, you can do some analysis and evaluate the risks for your own. Okay, so so I've a less than 100% is not an immediate guarantee. Don't use it. But it is an in a chance to make an informed investigation. Shall I shall I go ahead? Thanks. Exactly. So this is what dependable basically does. You enable it for your repositories and it starts sending you pull requests. And one good thing about a dependable that it actually supports many technologies. So it's not just about Java million. It also supports Gradle. It also supports other languages like JavaScript Ruby.net. Or if you use GitHub actions, go, you can also find package manager for them. You can see that some, some tools and the beta state. So it means that there are some changes happening there. For example, for Maven, at some point, there was a issue with multimodal repositories now fixed. They keep evolving in order to support advanced maybe features because you can pass versions through properties, through bill of materials, et cetera, et cetera. So what we use in Jenkins now, we use dependable for Maven, for JavaScript Ruby and for Docker. We will briefly talk about this packaging. And if you have any questions again, just ask. I have a few slides about enabling dependable. But again, let's just take a look at that in real before I have chosen one of my repositories, which is called job restrictions plugin. So it's just a plugin for prevention of job execution when user has no permissions based on ownership or other conditions and also for protecting master. So here right now, I don't have dependable enabled. And if you go to the plugin form, you can see that there are some dependencies defined. So we use a plugin form, the repository I was showing this version is 3.18. So it's almost 30 versions behind. We also have dependency on Jenkins core. And we have two plugin dependencies for test purposes. One is matrix project, another one is matrix authorization plugin. So what we will do here, I just have dependable interface somewhere, yes, here. So I need to enable dependable. I will be using SAS because I don't want to spend time. So if you use dependable in your organization, firstly you will need to add it to your organization. I will skip this step because we already have it in Jenkins. What we need to do next, we need to add our repository to dependency checks. So here I just click a button at the repository. You can see a number of repositories offered because at some point dependable access was granted for them. But there is no job restrictions plugin because I need to grant access. Why we need that is because of permissions. Dependable needs right access to code, to issues and pull requests because it needs to edit labels. It needs to submit pull requests. It also provides chart ops operations. And here we are going to just add job restrictions plugin. So if you are plugin maintainers, you will see only plugins to which you have administrative access. And if you don't have administrative access to your plugin, you just need to submit an issue and we will fix it on the Jenkins project site. So I save permissions. I granted access to this repository and then I will just refresh this page. Okay. And here we have job restrictions plugin. I edit it. By default it will be building for Java Maven for me. And that's what we need to do. So here you can see that there is job restrictions and there is a flag checking now. So we will need to wait for a while. And while we wait, I'll just press it with the presentation because I haven't tried it for this repository. I cannot say what exactly we will end up with. But let's see. Just a second. There are some questions or not in the chat. I didn't see it. Yeah, I don't see any questions there. Although I was noting that you were at the apps.dependabot.com website in order to manage those, to manage the permissions and the controls. Did I see that correctly? Yes, I use dependabot.com. But it's GitHub application. So it's connected to GitHub. All right. Great. Thank you. Okay. So let's wait. So I just opened this repository and you can see that there is already a first pull request landing. So if you enable it for the big project, you may actually receive dozens of pull requests on the first run. But in this case, there are not so many dependencies. So we can just let it run. And meanwhile, I'll talk about more advanced features of dependabot, which we actually use in the project. So release note references have already presented them. And actually, it changes well with the change log automation story, which we will discuss in the previous developer meetup. Because if you use GitHub releases, if you use tools like release drafter, you can get fancy looking change log, which is automatically generated. And you can pass it through downstream dependencies. So you get additional benefits for using GitHub releases for such change logs. Another thing which is useful for dependabot is comment ops. So let's go to our pull request, which was submitted somewhere. Okay. So here, dependabot, it has some front end, but you can also talk to it through commands. And there is a number of commands you can use. So for example, if you have some merge conflicts, etc., you can ask to release the change, you can also say that you please ignore this version. If you want to skip it due to whatever reason, you can set some additional configuration, for example, set the review versus assignments. But I didn't use these commands because there is a better way to do it. But these commands are available. So usually what, yes. Sorry, disrupting. I really have found useful to ignore this major and ignore this minor. But in my case, I think I had the wrong configuration, the things I was ignoring. I should have ignored in a config file at all. But Oh, whatever works. Okay. So we will talk about configurations a little bit later. But yeah, it's your choice as a plugin maintainer. In my case, I use rebase a lot. You can also use dependabot merge. And this is intelligent merge. So it will do a merge when CI passes, which is useful. And it combines with CI Jenkins IO, which builds Jenkins components. And yeah, there are some other requests available. Okay. So we also get a few extra pull requests coming in. So for example, this is our plugin form and for plugin form, what I wanted to show, yeah, this change logs. Again, these are fully automatically generated by other tools. So you can use them. And there are two plugin updates. So we can see that plugin form it passed CI. So I could just merge it. And we have test failing. So here matrix project, we tried to update plugin and it failed. So why did it fail? Let's see. Okay. It failed due to require upper bounds. Not surprising. And we will talk about it later in the presentation. So yeah, let's just move on then. So one another feature which Marcus has already hinted is configuration as code. Because indeed, you can configure everything for dependabot from web UI. But in such case, it's hard to trace dependencies. It's hard for other contributors to understand what's there. But you can configure everything using settings. And here you have an example. Let's take a look at another plugin, a strategy plugin. So here you can see that there is dot dependabot folder, and it includes config yaml. And config yaml includes some options. For example, here I say that I do dependency management for Maven in the root. So everything under the root, including submodels, will be checked. Check is a bit clear. There are some default reviewers assigned. This issue was introduced before code owners voted to GitHub. So I would say that right now it's rather obsolete, but it's available. So could you give some more words on code owners and how that applies here so I could skip default reviewers if I were using code owners? Yes, you can. Because code owners is a new GitHub feature which allows to set up reviewers on the global level or based on particular patterns. So for example here we have a GitHub team or all strategy plugin developers, and this team reviews all incoming code requests. So when new pull request comes in, it doesn't matter whether it's dependabot or not dependabot one, the team is requested. So yeah, this feature is rather obsolete. It's not something I would recommend to use right now. And there is a lot of other features available through configuration as code. Dependabot has really good documentation. And here for example, it's not also documentation, they also offer validation tool, which we can use to verify configurations. But for validation, let's see what we have. So you can set up scale, you can set up target branches, if you use multi branchy repositories, reviewers, assigns, labels, milestones, depending on your tools. You can either blacklist updates, so it's ignore updates or allow particular updates. If you want to laser focus the updates, you can set up auto merge. So if you are totally confident in your continuous integration, you can say that if CI passes just merge, no manual action required. Yes, so I've been using milestones in one of my projects, that's a GitHub capability. This will allow me to set a default milestone that should be assigned for, that's great. Okay, thank you. You've shown me auto merge updates, which I need on one of my plugins and default milestone, which I need on another one. Thanks. Okay. Yeah, you're welcome. So what else do we have? There are some languages and some languages also have additional features. So for example, for JavaScript, you can set up live updates because they talk to NPM, receive web hooks from there. So they get dynamic updates, no need to stop daily or whatever, same for Nougat, if you use .NET. But yeah, for Java, we have on there is at the moment, all these, but still is something useful. And if needed, you can always go to the web interface and trigger update manually because here there is a magic bump now, a button, which actually will trigger the updated needed. Okay, so what else do we have in this presentation? Yeah, one thing I want to mention that there is no or quite configuration support. For release drafter, for example, what we do, release drafter is based on the pro board. It's a common framework for GitHub applications and actions. And here we have global configuration, which covers the most of the use cases and this configuration is shared between plugins. It's not what can you can use an independent bot at the moment, but hopefully this feature is coming soon so that we want to need to duplicate the configs and we will be able to define common templates, for example, for Jenkins plugins, because yeah, I'll talk about it later. There are use cases we need to cover, but right now it's available on the manual. Isn't there already hiding in that release drafter that there are labels defined for release drafter, which I should actually use or encourage dependabot to use to flag a proposed dependency update? Yeah, right. So dependabot has default labels. For example, it sets dependencies label on every pull request, which it sends. And when you update the things, what we do in our tooling, we have category dependency updates, which also includes dependabot. So for example, here you can see that between releases 2.13 and 2.14, we had dependabots submitting full requests with configurations called plugin updates. And here is our change look. And there are other updates here and there. If you take a look at another tool like plugin poem, you can see that there are even more of these coming from dependabot, because there is just a lot more dependencies included there. So for example, here dependabot, here dependabot. So yeah, it definitely gets a lot of contributions across the Jenkins organization. Okay, another feature which I won't be presenting, but which worth knowing about is security, because dependabot also integrates with GitHub security. It's tooling which allows silent tracking vulnerabilities, et cetera. Again, it was introduced last spring by GitHub. And what dependabot does now it submits pull requests using security API. So you do not see it in public, but you see these changes as maintainers and you can properly handle them. For example, prepare CVs, prepare security advisors like we do in Jenkins. So updates which with known security vulnerabilities won't be displayed in common pull requests and you can rely on it quite safely. It was one of the main concerns when we started dependabot adoption, but it was at the rest quite quickly. So, Oleg, we had a request to ask a question from Sliden. Sliden, did you want to go ahead and ask your question now? Yeah, sure. Can you hear me? Yes. Yeah. So my question was that I think dependabot also updates Docker images. So does Jenkins use it to update Docker images currently? I'm not sure. That was my question. Yes, we do. So my plan is to finish with my event part because it's the most popular one. And then I have a few examples for the JavaScript and for Docker. Okay, cool. Thank you so much. Okay. I think you do. Okay. So let's speak about Jenkins specifics. So as I said, we started to believe in the dependabot in June. Right now, it's enabled in more than 60 repositories. A lot of development tools use dependabots and plugins use dependabot. And by the time of, well, in December, it created almost 2000 pull requests. So now maybe we are looking at something like 2500. I should have updated this slide. And I would say that dependabot really saves time because if you created this pull request manually, you just have to spend a lot of time if you want to prepare proper pull requests to reference change logs to reference address issues, but dependabot does it for you. So I found it really useful though. Yeah, first burst of pull requests sometimes makes you cry because yeah, in one repository, I've got something like 30 or 40 pull requests, sometimes major bumps with two or three, skipping two or three major versions of obviously say failed. But yeah, that's not the point. The point is that in common, when you figure out all these updates, it becomes quite reliable. And you integrate things credibly. So you don't need to spend too much time. Though there are some pitfalls to know about if you want to use dependabot for the plugin. One thing is that you should definitely use dependabot to update parent form and to update developer tools. So for example, if you use maybe plugins and other components, you should be using it because you just stay on recent versions that bug fixes in the case of plugin form. There is a lot of embedded tools like static analysis, injected test, and again, we update them automatically. So when you keep your parent form up to date, you get the recent updates. Also, what you shouldn't do is to actually update plugin dependencies to the latest versions, because plugin dependencies in Jenkins means a completely different thing than in common, for example, in Maven projects. So if we take a look, okay, let's go back to job restrictions. Let's take something else, configuration as code. So here, if you go to configuration as code plugin, you can see that there is a lot of dependencies that are deployed here. Not a lot. I definitely went to wrong repository. Okay, let's go back to plugin. Yeah, that one certainly declares several dependencies. Okay. Yeah, so what we have here, we define a few dependencies on plugins. You can see here, dependencies do not include versions because I suspect Mark uses a deal of materials now. On this experiment? Yes, that's correct. Okay, so again, wrong. Oh, oh, sorry. So that's, yeah, right. Okay. Let's take safe example. So role strategy plugin. So here you have some dependencies declared. You can see that there is plugin dependency. And here's another plugin dependency. And this plugin dependencies may be in different scopes. So for example, here we have a common scope dependency. It means that our plugin requires matrix authorization plugin version two to two. And if you let the panda boat to update this version, then the panda boat will push it no problem. But what it means that the plugin will actually require newer version of this plugin, and it will force all the users of these plugins to update, which might make sense. But you should be careful with that because your plugin users just lose freedom to manage other plugins. And sometimes if there are regressions in those three months, it's better not talk. Yeah. Oleg, for me, the distinction Hamcrest, for instance, here is altering generated code, not the later runtime environment. Whereas if I depend on a newer version of a Jenkins plugin, I'm demanding something from the Jenkins runtime environment. Exactly. So Hamcrest, he is a test dependency. And for example, folders plugin is also a test dependency. It means only that these plugins are used for testing. It still includes some requirements for transitive dependencies, but these dependencies can be relatively safely updated if you know what you want to achieve. But for these mandatory dependencies, you should be careful. Same for the Jenkins core. So here we have dependency which use Jenkins dot version. So what it means that it's minimally required Jenkins core version doesn't sometimes people do a mistake and follow a very recent weekly, just because it's more convenient. But again, it cuts off, for example, Jenkins LTS users and users of previous LTS versions. So our recommendation is to be careful with updates of Jenkins version and definitely not to pick a recent version. For example, what the practice I use in my plugins is to just stay behind two LTSs for my plugins. If you want to have more insights, how versions impact your plugin, there is a site called starts Jenkins IO. And here we can see plugin versions by Jenkins version. Let's take, for example, Git plugin. Oh, wait, wait patiently. That's a big page. Okay. There, yeah, it's, and this page is, I cannot sing the praises enough of that page in terms of what it helps you see about the distribution of installations of your plugin versions. Yeah, right. So here, for example, I have taken a role strategy. And you can see that the majority of my users are still on the previous LTS baseline. But, but, but they are on the previous LTS, you could, you can confidently say 2.190 is a safe version. If you're going back, you're, you're abandoning 25, well, okay, there are a bunch of users, one, one major LTS back. Yeah. So we had a Christmas break. So you can see that many people still didn't update to the recent LTS. We had a new security released announced for the next week. So yeah, I guess, you know, one week of this situation will change drastically. But according to plugin starts on January 1, this is the distribution we had. So the next month statistics will be more aligned. Okay. Anyway, let's go back to slide deck because yeah, we have some things to cover. So one other thing to be really careful of is library updates. Because library updates, well, they are like plugins, but they may conflict with Jenkins Core, they may conflict with each other. And for what it was, we also have transitive dependencies. Again, you should be really careful about them. Fortunately, maybe now offers tools which you can use. And these tools are included in our standard plugin POM. So if you use Jenkins plugin POM or if you use Jenkins POM for libraries, you get these checks automatically. There is maybe an enforced plugin which applies require upper bound through. It helps to prevent transitive dependencies. So you've seen an error I had in CI before for job restrictions. It's specifically this rule. There are also some additional rules, for example, the extra enforced rules which enforce some bad code compatibility checks so that you don't get updated to versions which don't support Java 8 anymore, for example. And make sure that you keep this rule enabled as well. So the default configuration is quite straightforward. If you don't use Jenkins, you can stop a plugin called maybe an enforcer. And in the configuration, you put a rule like require upper bounds. And after that, this rule gets applied with some tools. And you get the thing running. It helps us a lot with dependencies because again, when you bump one dependency, you may get issues with transitive dependencies. And maybe an enforcer plugin will show you a plug if something is not aligned so that you actually rely on all the version that you're supposed to use due to dependency requirements. So yeah, that's what we use. In addition to that, we have some tools which simplify dependency management because dependency management may be overhelming. If you take a look at Mark's plugin, how many plugin dependencies do you have, Mark? An embarrassing number and every one of them required, every one of them necessary. Okay. So yeah, if you want to see it in an offensive way, we just go to the plugin side. Yes, which is another way to view the embarrassing number of dependencies. Yeah. Some of them are optional, but still optional doesn't doesn't change that. Yeah, absolutely. Yeah. So it's a common situation for all the plugins. It's even worse because there are more in implied dependencies. But yeah, we have a number of dependencies. And you can see that Mark actually doesn't define so many dependencies here. Why? It's because he uses another tool called build of materials. So maybe you can declare dependencies in external repositories. And here you use, where do you declare bomb? Yeah, here. So here Mark declares plugin bomb. It's a repository created by Jesse Greek, which includes some plugin dependencies open it. Okay, so it's here. What it includes, it includes a set of plugins. Actually, quite a number of plugins. I just need to find. Yeah, for example, we can take one 50 baseline. And here you can, okay, I tried. Good to find the list. Okay. Thank you. One thing. So yeah, you can see that there is a bunch of plugins here. And the JC users tools like plugin compatibility tester in order to verify these dependencies. So you can consume this bill of materials and you can be more less confident that these plugins at least don't explode with each other. Because we use tools offered by Jenkins project, which verify these dependencies. And notably, this repository also uses dependabot. So you can see a number of incoming pull requests, which try to update versions. Currently everything is in red, because we have change in configurations, code, APIs, and I guess there are also some infrastructure instabilities. But generally dependabot is used in order to bump the dependencies. And here we can also see some fancy releases. Basically, again, we can see that plugin dependencies updated by dependabot. So if you want to simplify your life, for example, for test dependencies, especially if you use pipeline plugin, then going with Jenkins CI bomb is the recommendation. The Jenkins bomb that Jesse had created made my life dealing with workflow with pipeline plugin dependencies much, much better. I reduced significantly the time required to decode which combinations of plugin versions were allowed to work. Thank you, Jesse. Thank you. Thank you. Yeah. Another side of this, I think, is Jenkins core bomb. It's a new feature which has been added by Mike Cirooli and James Nord in recent Jenkins versions. So it's available starting from LCS 2.204, one which was released in December. But James has also created the backports for previous versions. So basically it's a file which includes information about libraries included in the Jenkins core versions. Because unfortunately, we had cases when the libraries were declared as conflicting dependencies. So sometimes it was leading to various kinds of binary conflicts. And these file aligns dependencies which are used inside the Jenkins core. And if you use recent plugin home versions, you actually have to enable a bomb manually. But we are working on a plugin, a bomb 4.0, which includes it out of the box. And here there is a reference to bomb. Basically, if you use 4.0 better, you automatically get these dependencies as a part of your tool chain when you use the plugin bomb. And you can get rid of explicit version definitions inside your plugin and rely on a plugin bomb to provide it. So you can be confident that each time you build, you build the dependencies required for this particular Jenkins core version. Yeah. So the recommendation for Maven, definitely use enforcers, definitely use a build of materials. If you use complex projects together with good CI and with dependable, you can get a pretty stable flow of updates coming for your project. I want to spend a few minutes on other languages and tools unless there are questions. Anyone? That's great. Keep going forward. I think we've only got about 15 minutes. So I think other languages is perfect. Let's please go ahead. Okay. So what else do we use in Jenkins now? We use Docker and JavaScript. Again, there are other technologies and tools you can use. For Docker, the use case is obvious because if you have Docker, you also have some dependencies. For example, let's open Docker file here. It's for Jenkins file runner. And here you can see that there are a few dependencies declared here. So this is multi-stage Docker build. And here I use a version of Maven. I also use a version of Open JDK below. And here I use a specific version of Maven. It's a right approach. So every time Maven updates, I will get a pull request from dependable. But here I use a tag. This is actually a better approach because, for example, if a new release of Java is delivered and if there is a security fix, then if I use such an approach, I won't get a pull request from dependable and might lag behind. It's not a problem for Jenkins file runner because it's in beta, but for other repositories, it's something you can see. And here's an example of Maven update because the dependable was able to discover Maven. It wasn't able to change the log because Docker Hub doesn't distribute information for official images. So for Docker, you can just get the version and then you have to figure out what's between these versions. But yeah, that's what we have. And for labels, I didn't set up filters. And here what I see is the Java version in this repository. No, it's in another repository in PluginCompat tester. Basically, I used the same approach for the development tool here. Hyperlink. So here you can see that there is update of Maven. And you can see one artifact which is, I would rather consider it as a bug in Docker. But basically, Docker tries to interpolate some versions. They use a lot of manual checks for common patterns. But here you can see that it parsed the version. It determined that a number on the end is actually a part of the version. So here's update from Java 8 to Java 13. As you may guess, it fails. Well, yeah, that's okay. But that's a terrifying proposal because this is saying change the Java, that probably means the Java version, right? And the Java version used to be 8 and they're proposing to go to something that is not a long-term support Java release and is certainly not Java 8. Yeah, good news that you can actually set up filters. When I was talking about what to update and what to not update, I forgot to mention it. But since we are here, let's return a bit. So if you want to set up some rules, what to update, you can use a configuration file. So here I have configuration for ignored updates. And here you can see that I ignore all Jenkins core dependencies. So basically, I don't update Jenkins core. I also do not update plugins located in standard packages. So for Jenkins CI plugins, I use Jenkins plugins. It's not a silver bullet because Jenkins plugins may be released with different group IDs, but at least it covers a majority of plugins. And if you're a plugin maintainer, you can set up your own filters. It's not limited to just these types. If I go to the dependable settings, you can see that they use GitHub API as an example. Much appreciated. But what you can see here, you can also set additional types. For example, version requirements. There are also other filters which are not mentioned here. You can ignore dependency types. So you can update on the test dependencies, on the common scope dependencies. So dependable got a lot of features for maybe already and counting. So yeah, you can set up your own filtering if you want to avoid the cases like that. But yeah, just keep in mind that obviously you shouldn't accept any update. Okay. So for me, the main idea, the main reason to have Docker auto updates is to actually have Jenkins agents auto updates, which is a nightmare at the moment for maintainer. And yeah, we will eventually get there. But right now, docket is also under evaluation for Jenkins project. Same for JavaScript, we have several plugins and components which use JavaScript. Nothing changes specifically. So dependable can determine NPM and can determine yarn and other standard packaging. And for example, I just opened the plugin site. And here you can see that there is a lot of updates coming for JavaScript. And well, it's the same as for everything else. For JavaScript, actually they have much better diagnostics just because there is a lot more JavaScript projects. And yeah, I'm not sure what statistic here. It just takes a while to load this information. But yeah, eventually it will also show information about failing pull requests, also change logs and other things. So you get the same for JavaScript. Basically for other tools, there are some specific Flux available. But it remains the same for almost any technology. So they know how there is how to parse files, how to submit patches, and dependable does it pretty well. The dependency check engine is more or less the same. Okay, just a few items as a summary. And then we will have some time for Q&A. So yeah, if you develop software, consider automating dependency management for your projects. It helps really well. It saves a lot of time in longer term. We already had a few cases when Dependable helped us to prevent security issues because Dependable picked the releases long before the advisory was published and finally we had it post factum. And yeah, if you automate the dependencies, there are tools for that. And today we presented Dependable. But again, it's just one example of a tool. You can also write your own tool if you want for your components. And Dependable is plugable, so you can write plugins for your language. And specifically for Maven, be careful about the transitive dependencies because the most of the problems come from there. If you don't use Maven Enforcer, just don't use Dependable to spend some time in order to add additional static analysis checks. And of course, make sure that you have a good continuous integration setup. So we work on Jenkins. So we are supposed to have a good CA and we actually have a lot of useful plugins. And if you measure your test code coverage, then it's great because you can also discover potential gaps where dependency updates are not covered. So yeah. For us, what's next is to document how we use Dependable. It would be also great to have global configurations. So for example, for plugins, we could have a common template, which defines a white list for dependency updates, which just gives plugin updates by default so that we don't have issues with that, which also disables some library updates because we have API plugins, which would be recommended way. And it would be great to configure that and then to facilitate adoption in more repositories. Because we are still at something like 60 repositories and adoption of Dependable is lower than for other tools because of the complexity. So if you could document that, if we could provide configuration, it would be much more convenient for end users of Jenkins. That's the plan. If you want to know more, there is a lot of information. So there is Dependable website, which includes documentation about configuration as code, about using Dependable, about some pitfalls. This documentation is quite good. We can also discuss everything in the community. Please use platform special interest group for Q and A if you want to follow up after this meetup. There is a developer mailing list where we discuss Dependable evaluation. It was not detective for a while. There were other threads. But yeah, if you want, you can use this one. You can use this one. There is also a bunch of examples, some of them I presented today. So you can just Google for them and check out how we configure and use Dependable to know our repositories. Okay, that's it from me. And thanks to everybody who was on the call. I guess now we have some time to answer questions. And Slavin had another question. So he notes in the chat that part of his proposal for Docker polling project as part of Google summer of code was to send pull requests to repositories when a base image update or security patch had occurred. Could this be done with Dependable or is it rather better to be done with a separate plugin? What's the preference? So one of the problems. So Dependable relies on databases for updates. And there is Dependable doesn't use specific databases, which identify about security updates earlier. So if you are comfortable with eventual updates and eventual security, then Dependable is probably fine. But for example, if you're a customer of organizations, which notify you about security vulnerabilities, which provide proactive scans and other tools, then you might want to implement something on your own. Whether it's a common use case, we had that, but I'm not sure how common it is across the industry. And this part still makes sense. Also, if we talk about JSOC project running security scans for Docker, it has to happen somewhere. For example, in Jenkins, you can use onshore and other tools, and you can provide triple dependencies based on that information. Again, Dependable doesn't provide you much insights or why this update is needed right now. It provides some metadata references to CVs, but you would still need to analyze the impact of this update. Thank you. Any other questions, comments? So you mentioned that there are sometimes security notices. So I received a security notice for a particular Jenkins plugin, a total of 25 installations, a tiny number of installations. Was that coming from Dependable? I thought that was coming from GitHub. What can you teach me about that? So what I can teach you about that? Well, basically, I couldn't teach much without the disclosing potential vulnerabilities, I guess. So the one that I had was UI themes plugin, UI themes-plugin, and it was just an out-of-date dependency. And it said, this dependency is catastrophically out-of-date. It needs to move forward this large number of steps to be fixed. Yeah. So one thing about it is that Dependable is deeply integrated with GitHub now, and at some point, it doesn't really matter. So for security, I believe they use Dependable on their own whatever you configure. It is Dependable course to suggest the dependencies. But if I recall correctly, the full requests are still referenced as Dependable. Okay. Thanks. I can double-check, but... No need. I was trying to comprehend what... I was really pleased to get the notice. It was great to be told, hey, there's a problem. And then think about what does this problem mean? Yeah. If you're interested to know more how Dependable is organized, actually, there are repositories. Dependable itself is open source, so you can just check it out. You can find out the logic, and we had to do it a few times to understand why it doesn't behave as we expected. So Dependable is mostly written in Ruby, but the code is quite good. One thing to keep in mind is about license, because it's not MIT license. Basically, you can use it for non-commissioned purpose, as you wish. So, for example, we can take it and run Dependable as CLI tool on Jenkins infrastructure, actually, if you want. But if you want to make this a commercial feature, then do not. Okay. So it is not a BSD or MIT-style license. Got it. But for us, as Jenkins community, it's perfectly fine. But yeah, we use Dependable as a GitHub application, because Dependable, when it operates, it pulls change logs, it pulls GitHub, so it would consume REST API limit and other things. So for us, it's more convenient to use GitHub. Well, Oleg, we have just very nearly reached our time. Anything you want to say in conclusion? Nothing from me. Just tame your dependencies and be careful with them. Thanks a lot for your time and for watching this video. Thanks, everybody. We'll end the meeting now. The recording will be posted to the Jenkins YouTube channel. Thanks very, very much. Thank you.