 Hi all. Welcome to the Jenkins developer webinar. Today is May 18th and we have James North who will present PluginPom 4.0 and the changes in bed. Before that I will do a really quick opening and then we will press it with the technical content. Okay, do you see my screen? Yeah, so quick introduction to the Jenkins online meetup. We are doing regular sessions for Jenkins users, Jenkins developers and the main objective is to share any kind of experiences for developer meetups or what is by contributors for contributors. So basically we do a really relaxed discussion. The main focus is to do show and tell and live demos and everybody is welcome to participate to ask questions. We are ready to unmute you if you want to ask questions. Actually it's our first developer meetup which we do in a Zoom webinar. If it doesn't work, we will switch back to Zoom. And thanks to our sponsors, Continuous Delivery Foundation and QALB switch provide us equipment and other things to get these webinars running. So as I said everybody is welcome to participate and if you are just starting contributing to Jenkins or if you're interested to do so, we have a good page on the Jenkins IO website which describes various ways to contribute. So if you're interested to do any kind of contribution like submit some code or maybe participate in design, participate in documentation please refer to this page. And the results are good opportunities to contribute next week because we are starting a UI UI hack test. It will be a weekly long event where everybody just works on user interface, the communication or shares experiences about Jenkins and good news at the end of this event you can get special swag and prizes. So if you're interested there is online page for that on the Jenkins IO website. We are still working on a final list of project ideas but there is a number of good areas and if you're a plugin maintainer you're also welcome to propose stories related to your plugins. If you want to work on something specific again please feel free to do so. It's not a hackathon, it's really a hack test and everybody is welcome to contribute on any stories which would improve for Jenkins user experience. Okay and we can talk a bit more about it later and yeah I'll just finish the slides. So if you're interested to present anything related to plugin development or development in general it can be best practices like how to do static code analysis or how to properly deliver real code with Java or with Jenkins. Please let us know we are looking for speakers as for anything else. For this particular meetup again it's a developer meetup so we will be adding everyone to final list or training voice permissions so that you can ask questions. James what's your preference would you like to get questions during the presentation or after that? Sorry just had to find the unmute button. I don't mind I work okay with interruptions during a meeting. If you want to save them till the end as well I've got a section at the end for Q&A whatever the person feels happy with. Okay thank you and the fourth line we have Jenkins developer at least we have a number of charts where you can ask and also we will be sending our feedback form just to collect some additional details so everyone is welcome to attend and I guess this is from me so please welcome James Nord who will do the presentation itself. Are you going to monitor for questions during because I presume everyone's muted by default then. I am muted everyone and if you just join or if you cannot ask a question please use the Zoom 20 or chat and you will handle that. Okay can you see my slide correctly? Does that come through? Yes we can. Okay so today I'm going to talk about the plugin parent POM 4.0 and later and what that means to you as a plugin developer what you need to do and why we actually went about and changed it. So a little bit about me I am a principal software engineer at CloudBees working on a commercial product built on top of Jenkins. I work in a team that is responsible for over 50 plugins so every time we had to change something and if you look after one or two plugins in open source you can kind of scale that up to 50 and we probably hit all of the issues much more frequently so a lot of that was the driving force for trying to address all the problems. So mentioned some problems but kind of let's just explain what they were so why we actually tried to do what we did. I think the biggest pain that we all face is every time we change the Jenkins version you will find five million dependency errors caused by something requiring a lower version or a higher version than what is actually included so something wants to use commons codec 1.9 something else wants to use 1.12 you end up using the 1.9 and then that can cause issues just when running your unit test with things not working correctly or kind of at runtime the worst case is you bundle a library and that conflicts with something else in a different plugin that's expecting something to come from core and has an optional dependency on your plugin and then doesn't. We have a deprecated tooling in the plugin POM so the GMaven plugin reached end of life and wasn't actively developed there was a few issues with it that obviously we're never going to get fixed. Finebugs and the finebugs maven plugin had been inactive for two plus years. If you were new to Jenkins plugin development and you knew maven but not Jenkins plugin we'd quite often confuse you. We'd use a flag that was set in maven for example skip tests is commonly used to skip running unit tests in the maven surefire plugin but if you did that in a Jenkins plugin it also wouldn't run your finebugs analysis and it also wouldn't create any javadoc. So I would say you wanted to create a bundle quickly to give to someone which had javadoc and everything else running mvm package dskip tests you would expect that to happen but it didn't. Another way that we would confuse you is if you wanted to run multiple tests in parallel you would specify that with concurrency but surefire already has a way of doing that and it's called four count so all we did when you set concurrency was to then set four count but if you knew four count existed and you tried to set it it just wouldn't work as expected so we had a barrier of entry to those that knew maven. If you didn't know maven there was a little bit of a barrier of entry because your google searches would tell you how to do something in maven and then when you use the plug-in POM it would actually behave slightly different and kind of I think there's something that was a little bit it was a great intention but unfortunately it had a lot of bad consequences was the plug-in POM allowed you to do bad practices so if you wrote a flaky test or were still flaky production code the unit test would actually run five times so if it failed first time it would run it again and again up to five times and it would only fail the build if the unit test failed five times in a row so this had a couple of things it allows obviously flaky tests and flaky production code to come in nobody really looks at the output in the console a lot so the fact that you'd introduced some flaky tests or flaky production code would go missed and it allowed race conditions to be accepted as the norm because they just weren't they weren't spotted and last but least not least there was some unused and untextured complexity in the POM so since Jenkins 2.54 254 it is required Java 8 to run so there is no need to really build any plug-in with Java 7 you can build them all with Java 8 if you're targeting anything not ancient and if you are targeting something ancient then you don't really need to update the plug-in parent. The JGit if anyone are aware of JGit it is a Java implementation of Git provided by Eclipse and it used or had a profile for using JGit as an SCM as opposed to using the native Git tool when performing releases and I don't think I've ever come across any need of any plug-in doing that so almost everyone has got Git installed I'd be surprised if it even still worked. So I said before in CloudB as I had 50 plug-ins across the team as part of those tests every week when a new LTS comes out we have automated jobs that rebuild all of our plug-ins on the latest master against the latest Jenkins weekly and it does that by kind of passing in the Jenkins.version which you can do on the command line so mvn-d Jenkins.version equals whatever we've just released that Friday test and more often than not we would find we were being hit by not actual production code issues but the library conflicts and issues. So rather than actually finding issues in the latest LTS or incompatibilities sorry incompatibilities in the weeklies with our plug-ins we just ended up finding there's another library conflict there's another library conflict and there was more false positives than there were real positives. So having gone through some of the problems what were the actual solutions? The biggest one and the one that took a while to actually get right was introducing a bill of materials for Jenkins call. So a bill of materials allows you to with Maven define a set of artifacts and their versions and you can define that in a project and then you can consume that in all other projects. So it's quite common to do with spring if you're used to using a building a spring boot project you can just import these spring boot bill of materials and then all of the spring libraries and their dependencies will be set to the correct version for the version of spring boot that you are targeting. So the bomb was first introduced in Jenkins 2.195 and because we actually want people to be able to use the plug-in POM without having to go to at the time the most recent and weekly we still needed people to be able to target older LTS releases. We specially published old versions on all the LTS lines going back to 2.164.1. We still have a few core libraries missing so commons codec was a notable one that's missed and there's a pr2 at those and all other outstanding libraries into the latest weekly and it's not just a plug-in development where the bomb comes in handy. So the Jenkins file runner or the Jenkins warpackager also benefit from just having a core bomb. So the fine bugs given it was dead that was switched over to spot bugs. Any property in the POM that was using fine bugs was changed to spot bugs and the exclusion filter was renamed as well excuse me and one thing to note here is if you're targeting a recent Jenkins core so probably one that's gone in in I think the last four weeks all the use of JSR 305 annotations have been removed so it's now almost in its entirety only using the spot bugs annotations. There are a couple of annotations from netJSIP but they are in the minority. The gmaven plugin was switched over to gmaven plus only really applicable if you're using groovy compilation or tests as part of your plugin. I haven't been on any of my plugins so I can't really add anything here unfortunately but it has been tested by someone that has been using gmaven. The standard maven properties have now been switched over to using so there is no more concurrency in in the POM it's now using fort count so if you find a maven property documented in kind of a maven plugin or anywhere else on the web in a plugin that we use setting its property should take precedence over anything else. Skip tests now only skips tests that does have a downside and one of the downsides for having that is if you wanted a quick build and people did use skip tests for hey this is a quick build because I don't care about the production quality of it you now no longer have that by just using skip tests so because of that we introduced a new profile so if you actually want a quick build of just build up a hpi so I can run it there's a profile quick build so mvn-p quick build that will give you a build obviously package at the end of that that will kind of build up the hpi and anything else that would produce a final artifact but skipping anything that does not affect the outcome of the final artifact so the enforcer rules will be skipped spot bugs will be skipped unit tests won't be run if you use the maven invoker to run some extra tests they will be skipped the access modifier checker will be skipped so now we've kind of gone through all of that it's kind of like okay what do you need to do so the first thing you need to do is obviously use it so update your parent to 4.2 4.2 is the latest today so it's always best to go with the latest rather than the 4.0 a couple of things have been tweaked and fixed and some libraries and plugins have been updated as well yeah if you have specified your Jenkins version you will need to change your Jenkins version the default in 4.2 is 2.204 I said earlier you can use anything from 2.164.1 through all the LTSs or any weekly from 2.195 bit more manual work is any version that you've specified in dependency management or dependencies that is now coming from the bomb should be removed this is is legwork you have to kind of go into the bomb have a look at the dependencies it's specifying there for all the artifacts and see if you've declared them if you have safely deleted if you have declared them in the dependency section as opposed to dependency management section and they're using Eclipse Eclipse will tell you you're overriding a managed dependency so you can just remove it if it's in dependency management Eclipse doesn't help you I've not seen anything in IntelliJ but I don't use IntelliJ day-to-day so I might be missing something James so yeah so forgive the injection you said you're okay with me interrupted with questions yep so in this case I just iterate through the dependencies in my plug-in and if I delete a line and it still compiles that's generally healthy so delete an entry so so I would uh if I can you see the GitHub page now sure can't right um so inside here we have the let me make this bigger so people can actually read it inside here we have the dependency management section so anything that's in here for the obviously for the Jenkins version you're targeting so this is for 2.222.1 anything in the dependency management section so spot bugs annotations jzip annotations and commons io commons lang anything reported here even slf for j if it's in this section you can remove it from your POM you can remove the version from your POM so if it's in dependency if it's in dependency management you can remove it entirely if it's in dependency if it's in the dependency section you can remove the version so you would still end up with commons codec commons codec but you wouldn't have a version specified thank you does that make sense that did thanks very very much so so at minimum I could get rid of worrying about the version number yep I may even be able to get rid of explicitly declaring the dependency if it's not required for my compile thanks great um so another thing that has changed in plug-in port in the plug-in POM 4.2 was html unit was updated um that was needed to fix the Jenkins test harness um and unfortunately html unit is not backwards compatible so if you're using web client-based tests you will likely need to kind of fix up the api breakage in your tests yeah it's the kind of classic issue every time we upgrade html unit we have to explain the compatibility yeah um so any uh properties or files um that you were using so if you had defined concurrency so you run by default with two forks as opposed to one um you'll need to change that to fork count um anyway you've used the um find bugs properties you will need to replace those with spot bugs and if you've got a custom spot bugs uh excludes filter in your project source you will need to move that to source spot bugs as opposed to source find bugs and yeah james so it looks like your screen first or you're just no i'm yeah i'm sharing the wrong one um right let's go back a bit um um so um yeah find bugs and spot bugs um you just run said on changing the property the flaky tests um there is no easy way to fix the flaky test or flaky production code um and the first issue is actually being aware that there is flaky tests um you'll now probably see them um more often than not because as soon as the test fails it will fail the build um if you want to run it locally just run stuff locally overnight and if it passes every single time whilst running overnight then it's probably good enough um easy way to do that if you're running on a linux or a unix-like operating system and using bash um while maven test do done and that will just loop and run maven test forever and ever until you either interrupt it or a unit test fails um so uh i did this earlier this morning an example of something um so this was all i needed to do to update um the kubernetes credential provider plugin from 3.49 to 4.2 um i chose 2.190.1 uh it's the jenkins baseline i wanted to target um mainly because of commercial reasons um and claubies supports um some older versions than the older lts so that's lts so that's the most that's the oldest version that claubies supports um i removed uh an override for not uh rerunning flaky tests because i don't need that anymore because it's it does that automatically um because i'd updated the jenkins version um the ssh credential plugin no longer worked correctly because it couldn't find um some ssh key passing that it needed um so i needed to update that to 118.1 which meant i also needed to update the credentials plugin um i no longer needed to um depend on j unit uh i no longer needed to include spot bugs annotations um hamcrest was going to call and i didn't actually need before to depend on specific moquito and power mock versions but the version of the plugin parent i was depending on had a bug where um the moquito and power mock weren't compatible at the time i started um so i had that in so i just took the time to remove that um and that was pretty much it for that plugin there was no source changes i needed to make at all um so what else should i look out for um if you're changing your dependencies um it's always good the first time you run it locally is to actually see what is included inside your hpi so inside your plugin um make sure that there's nothing there that you're not expecting so for example when it bundles something you will get a warning output from the maven hpi plugin telling you that it is bundling something um so in this case it's bundling json which comes from the slack api client um i had a direct dependency on the slack api client so that's being bundled which i also have a dependency under the few direct dependencies and then there's some transitive dependencies that will be in bundled that i may or may not have uh expected um so in this case looking at all of those for my plugins like that's that's fine i'm done um i can release i can ship it and i can move on so so james again forgive my getting an education but transitive dependencies then do you generally choose to exclude them if they're being included how what's your thought process there is that for a separate session and i should delay the question no that's perfectly okay um most likely uh transitive dependency so that's a dependency of something that you depend on so you may only use an api um or you need an implementation say there's an api in an implementation and you depend on the api and the default implementation and then the default implementation because it's speaking to some web service um will rely on say an apachi hcdp client which is a great one to choose um so that would bundle then the apachi hcdp client in your plugin um lots and lots of plugins depend on the apachi hcdp client and it's probably not great to have 500 million copies it's a bit of an exaggeration because we've only got however many plugins we've got in the jenkins ecosystem um but you know you don't want 20 25 versions of the apachi hcdp client uh in use and then if someone else depends on your plugin and the apachi hcdp client as well they're going to get the version of the apachi hcdp client from your plugin um which if you don't update it could be outdated might not have the library that they need to satisfy their use case so for the hcdp client use case there is actually a hcdp client plugin that provides the apachi hcdp client so in that case i would exclude the dependency from coming in transitively in my plugin and add a dependency to the apachi hcdp client plugin okay so so i need to think carefully about those transitive dependencies when i see them thank you yeah yeah transitive dependency is all waste danger and that's why builds of materials are generally useful because it increases your chances of avoiding binary conflict but if you start suppressing uh issues and excluding library engine this is basically suppressing issue your three scope getting into something yeah and because of where the dependency for jenkins core comes in even if um so you're using commons io that should come from jenkins as opposed to from your plugin if you bundle it in your plugin it won't be loaded unless you start using kind of the plugin loader hacks that are out of scope for for this session so you will unnecessarily include it although using the 4.0 palm it will be set to at least the correct version so it might be that you know you look at them and go oh it's commons io i know that should come from jenkins but due to the way that the hpi plugin has seen it it's coming from a closer dependency in my dependency chain than from whatever's requiring it in jenkins core it would choose to package it inside your plugin arguably something that's suboptimal in the hpi plugin but also it's a little bit out of scope and requires a lot more engineering effort so if you see something that you know reasonably should be provided by jenkins and the way to look at that is to go to the jenkins core bomb and if it's defined in the jenkins core bomb you know it should be coming from jenkins so at that point you should probably exclude it yeah it's probably a subject for improvement and maybe an hpi plugin because we can detect this case automatically and that is was a lot of the a lot of groundwork by james jc and daniel to capture these cases we can still do more we add any more questions yeah so for me the interesting question is about the extent of a bill of materials for example we have components like models which we still do not include in our bill of materials so what is your opinion about them james does it make sense to include them i was kind of sitting on the fence on them so i to me anything in the bill of materials i think should be safe to use and kind of be blessed and that's where i'm kind of like the core libraries like commons io commons lang the things that we've been everyone's been consuming for a while are fair game some of the more esoteric libraries not so much so but i can understand the use cases for it so i'm not against it i'm not for it i'm kind of like i'm i'm sat on the fence as it were what i think we should probably have is a better thing to say you're using this but we really don't think you should be using this so there's there's probably a quite a few libraries that come in from oh well there's there's obviously like if we look at the spring libraries probably not the best to be using we know that people do use them it might help if you brought up your pull request i like yeah sure i was just looking for bond dependencies and the bond imports to demonstrate your keys yeah but yeah i can just so yeah add a non-deplicated and the jink is called libraries this one yeah so it really is i think it makes things easier but you know at the same time the windows package checker i don't really think anyone should be dependent on that probably the same with b crit yeah you could clean up this list before merging but i understand where you're coming from because at the end of the day that is a bill of materials for Jenkins and that is what Jenkins will bundle and will ship with so you know it's yeah but still Jenkins has hundreds of dependencies some of them yeah we would be happy to get rid of them but if you get rid of something basically you remove API and you never know where you go and i think that's kind of where i'm in my head this is coming from so anything that would be an API for Jenkins or be exposed in an API for Jenkins should be managed in the bill of materials things that are just things that Jenkins need to be able to run should be outside of the bill of materials and shouldn't even be exposed to plugins that's where i would like to get to that's a massive amount of work in itself which you know need to change the class loaders and things like that and all the tooling that everyone is used to using so you know it's not a simple task it's not a task that anyone has signed up for or there is quite a bit of there's a couple of big jeers around it as well as making the Jenkins test harness use more realistic class loading which would be needed as well if we started having dependencies that Jenkins had but we didn't want you to consume with your plugin as well as then going well you built this plugin on the Jenkins before this came in so actually we want to expose all of these to you that was a that was a long answer for me going i'm not sure there is definitely a lot of work to be done there though yeah bill of materials is a great first step because it already prevents a lot of binary compatibility conflicts and binary compatibility conflicts a big problem for Jenkins users in the moment yeah and it's probably one of the the biggest reasons why people don't update their Jenkins plugins to the latest Jenkins version or or a more modern Jenkins version when they start developing the plugin or when they make make a change it's because well if i do this i know everything's going to break and i'm going to have to spend 10 15 20 minutes going through and fixing the enforcer issues and i just want to write code so this should hopefully mean that at some point we'll be able to go through and all these plugins that have been detached from core that keep coming back in because you have a you you depend on a plugin that depends on an earlier version of Jenkins core but you don't actually need the detached plugin that should make it simpler and the less plugins you're having Jenkins the quicker it is to start up the less memory it uses so it all kind of comes around and makes Jenkins a better place by people moving forward and using a more recent Jenkins so one question which is probably well i know the answer but it might be useful for potential viewers is what is the difference between Jenkins core bill of materials and plugin bill of materials yeah i i kind of had that on the slide and i really just skimmed over it so the Jenkins core bill of materials is targeted at the libraries that Jenkins provides and runs with the Jenkins plugin bill of materials is about knowing that you can have a set of plugins that you depend on that are all compatible with each other and the version of Jenkins that you are targeting so if if you're looking at you you want to use a version of the the common use cases workflow plugins you need to depend on workflow cps and test scope but you also want to have the workflow step API because you're implementing a step and you're targeting Jenkins 2.190 you know which versions of all of the workflow plugins should you be depending on and so that is where the Jenkins plugin bill of materials comes in which is what Oleg is showing now yeah so basically it addresses similar use case but for plugin interdependencies which might be also a challenge to my team and another issue oh not an issue another big difference between the Jenkins core bomb and the the plugin bomb the Jenkins core bomb is set in stone at the point in time that Jenkins is released the plugin bomb is live and is updated as new plugins that are compatible get merged into that so here you can see that there is dependable basically dependable picks up all dependency updates and suggests them well usually it fails because there is a lot of integration testing setup here so when you see a dependency which is not merged most likely there is some things to be cleaned up before it can actually can go into the bill of materials but the good news that this repository does it for you because otherwise you as a plugin maintainer will have had a serious chance of hitting the same issue here you will get a snapshot where all plugins are cross tested and at least you can use them with some confidence that they do not conflict to which you use each other whether it's a binary conflict or functional conflict there is some test coverage here so are there any other comments or questions so everybody should be unmuted and if you have a question you can just ask so James is it so just to for clarity to me I could potentially use both the Jenkins core bomb to get the the version numbers that it describes and the plugin bomb or is that am I choosing one or the other so when when you use the Jenkins plugin parent version 4.0 you will get the Jenkins bomb you have no choice in it it is imported you can then go and import the Jenkins plugin bomb yourself in your plugin and the two will happily coincide side by side and now but there is a Jenkins version number inside or Jenkins version parameter or definition for the plugin bomb but I've also set that in my palm.xml so should I keep those generally the same they are slightly different versions so the version when you're setting the version for the Jenkins core that you target will be a full kind of LTS release for the plugin bomb it is targeting a line so you're targeting the 2.164 line or the 2.190 line so you need to say which artifact so thanks for highlighting that you've got the artifact ID which is if you're targeting the 2.164 line you'd say your artifact ID is the bomb 2.164 and the version there is the most recent version of that bomb that has been published because it will be constantly be updated and published as new plugins are or existing plugins are updated in that plugin bomb. Thank you, thank you very much. There is a question in the chat from Boris about if there is a way a bomb equivalent when developing a plugin that has front-end components as well. Not currently I know if you're trying to do anything on Blue Ocean that is a particular pain because you need to use the exact same version of everything that Blue Ocean is using to make it compatible. I'm not aware of any Blue Ocean extensions apart from one proprietary one that isn't in the main Blue Ocean tree. I know that early Hafner has been working on having kind of a more modern front-end for some of the plugins he's using and he's actually shipping libraries or the JavaScript libraries in plugins and then depending on those plugins. I think there was a talk recently about that, Oleg is that correct? There was a blog recently so if you're interested, yeah do you see my screen? So you can't connect to localised? Oh yeah, so I do a lot of development locally so yeah sometimes it becomes a hot hyperlink but yeah here if you go to the blog you can see a blog post from Oleg hands-on beautify the user interface of Jenkins reporter plugins so you can read through this blog post and get all the information and if you want to see Oleg live actually you have an opportunity for that because next week again we have this UI UX hackathon during this hackathon we organise a number of sessions for developers and for users and here you can see that just in one week Oleg will be presenting the same talk during the online hackfest and you're welcome to join but in principle it's a lot about dependency management and how to integrate common components and hopefully soon we will be able to provide the build of materials or standard framework which would allow doing it easily. Are there any other questions? So then thanks to everyone for your time again it's our first experiment is doing developer meetups in Zoom so if you have any feedback we shared a feedback form link we would appreciate any comments and hopefully we will have more developer meetups so next week we will have at least four we still haven't decided how we would be hosting that whether it would be online meetup or whether we will move to another meetup group but we plan to do more sessions and if you would like to join and share your experiences about Jenkins so to provide a show and tell about particular use case how we develop plugins or how you develop pipelines for what it was please let us know and we will be able to host such event so thanks a lot to James for this presentation it was really useful and we will be hosting it on the Jenkins YouTube channel soon so hopefully other plugin maintenance we will be able to see that and update to plugin form for the zero soon. Thank you for organizing this Oleg. Thank you too so any closing comments or feedback before I stop the recording I guess not so yeah thanks all and see you at the next sessions.