In my work as buildmanager, I have installed a couple of Hudson/Jenkins instances from scratch as well as assisted in maintaining of a lot of them. While all installations have their differences (a Jenkins installation for a single project with over 200 developers – in various branches – is radically different from the typical, medium-sized, single project server), I found myself installing the same plugins again and again.
To help you set up a new instance, here is my master plugin list, complete with some pointers on how to use them. (Note that this list grew quite long, so feel free to just browse)
As always, your comments are welcome.
This plugin is your swiss army knife when it comes to notifying your developers of various events. It allows you to define complex mails for different build conditions (even sending a mail, before the build runs!), different mails to different recipients and even create your mails by jelly-script.
Mails generated by this plugin can contain a wealth of information, which can be custom tailored to its intended audience.
Here are some useful ideas that I used this plugin for:
- Notify all developers that a deployment on a test-machine is about to start (and thus the machine will be unavailable for some time)
- Notify testers that a new version of the software has been deployed and is ready to be tested, complete with a list of resolved issues since the last release
- Notify developers that a tycho-based build of custom-made development plugins has been compiled, approved (via promotion plugin) and can be retrieved using eclipse’s update mechanism
- Telling a developer that he has potentially broken the build along with a list of dire consequences (“You seem to have broken the build with your commit #xy. Until this error is corrected, no new changes will be included in hourly deployment to our sandbox server. Please address this issue immediately. For more information see http://xxx“)
Note that in most of this cases I do not replace Jenkins’ standard mail functionality (for CI jobs), in fact I found the email-ext plugin to be the most useful for manually started jobs and promotions (in case of promotions, however, there is one major bug to be aware of: see JENKINS-10812)
A very useful plugin. The basic idea is as follows:
We have two (Maven) build jobs, say Util and Business, where Business depends on a snapshot version of Util (both are to be released together, but are being maintained by different developers, thus they are split into two different jobs). Business has “Build whenever a SNAPSHOT dependency is built”-trigger, this whenever Util is built because of a source code commit, Business is built afterwards. A change to Util (say: API-change) might result in a perfectly working CI-job for Util, while Business breaks or becomes unstable due to failing tests.
Who is to blame in this scenario? Our Util developer did some breaking changes without considering the implications for his fellow developers. But he might never notice…
In comes the Blame Upstream Committers Plugin, which checks every upstream build of the failed build (in this case, the last run of Util) and adds its commiters to the recipient list. So now our savvy Util developer immediately gets a mail informing him that his change might have lead to a breaking build of business (which might prompt him to write a message about his change to the developers of Business).
This little plugin can be a real killer, if everyone uses it. The idea is very simple:
As soon as a build fails, it should be top priority of the team to fix that broken build (with the supposed culprit in the lead). The problem with larger or distributed teams is to see, whether and who is working on the problem – and how long it will probably take.
The Claim plugin solves this quit neatly. It allows users to “claim” a failed build, marking it as his responsibility. A useful claim includes the reason for the failure as well as how long it will take to fix it.
Using the claim overview, buildmanagers or technical project leads can now quickly take a look at all failed and unstable builds that have not been claimed yet and react accordingly.
A very simple plugin that providing a column that can replace Last Success and Last Failure columns with a compact combination of both data. Quit useful when combined with claim or sectioned view plugin, since screen real estate becomes quite important.
There’s nothing like a diagram to show the inter-dependencies of your job. This plugin creates a such a diagram from the up/downstream information that Jenkins provides, therefore it works with most plugins that create additional dependencies.
This plugin allows to divide a view into different sections. It is not as versatile as the dashboard plugin, but you can create useful overview pages very fast. Allows you to quickly organize your Jenkins visuals according to my basic rule “view borders are audience borders (aka different teams get different views), section borders are category borders (make different sections for CI builds, nightly builds, deployments, etc…)
This plugin allows a job to call another (parametrized) job using preconfigured parameters (which can of course be created during the calling job’s run). While possibilities seem endless, there are two main usages for me:
- During nightly named releases, a Maven release is created. I use the parametrized trigger to pass the exact version to auxiliary jobs (such as deploy, smoke- and Selenium tests). Stay tuned for an upcoming post about my technique of creating named releases – and about my reasons
- A very useful parameter to pass on is the subversion revision – and the receiving job does not even need to be parametrized. In short, you simply call the second job with this parameter, and it automatically uses the subversion revision that your main job had checked out. Useful for failfast -> smoketest -> longtest-scenarios.
All builds using Maven are equal, nothing special here, as far as the theory goes. Reality, however, plays a different tune. Each project has it’s peculiarities. Perhaps you want to check whether all bundles in a OSGI-container have been started. Or you want to mark all jobs in your build-history that included a database change?
Groovy Postbuild plugin does all this for you. It allows you to add execute a script add the end of your build doing, well, almost anything that can be done on the master node – the script runs directly in your Jenkins VM. One word of warning, however. You might be temped to throw lots and lots of stuff in there, tune until it works and leave it at that.
Take your groovy script, and turn it into a real Jenkins plugin – it is really easy and you have all the benefits of a real piece of code (sourcecode management, unit test, you name it). I might be tempted to write a short tutorial about doing just that, if you are interested.
This is another useful plugin to wire jobs together. It allows you to place information about success of downstream job right in the upstream job (as a so called promotion, which is basically just a colored star in the build list). So, let’s say, you have a job that deploys your software on a test server and a second job that performs some smoketests on the deployed project. Now, using the promotion plugin you could define a promotion criteria “smoketests successful” that is triggered whenever the post-deployment smoketests complete without error.
Promotions can include actions (most things that can happen inside a build job), allowing you to do certain things only when the tests were successful (like deploying the artifacts to nexus – which only works using Jenkin 1.449 or newer, triggering nexus pro staging doing a git push).
Finally, promotions can be manual steps (i.e. a user has to approve the promotion) which starts the promotion actions (release to production, for example).
Here are some examples of usages of this plugin in my projects:
- As stated above, server application has been built (main job), is deployed and all smoketests passed
- Some XText grammar plugins were successfully compiled and basic tests were performed. As a manual promotion, the commiter or architect can release the created plugins to the developers, which copies them into a public p2-repository and sends a notification email to all developers.
Simple plugin that periodically checks the file system size of all jobs (workpace and build history), displays a diagram with each job and provides a list of all jobs and their respective sizes. So when your system monitoring complains that your file system is almost full, you can have a look here to find out which jobs might be hogging your system.
Does what it suggests. Simply stores old versions of your job configurations upon changes. Restore is still manual. If you use this plugin, don’t use the default path for the history, put it into a directory outside of your builds (it creates lots of small files which you don’t want to be cluttering your build dirs).
Another very simple plugin. Puts a timestamp before each line in a build log. That way, you can easily find out which build step is taking so long…
For those of you that don’t know JavaMelody, it’s a java based monitoring suite, that gathers all kind of statistics about the usage of a JavaEE application. It’s invaluable to scale and size your production servers (you DO consider Jenkins productive, do you?). What this plugin actually does is twofold: 1) easy installation of Melody and 2) link on the “manage Jenkins” page.
Really small plugin that simply regularly cleans (empties) your Jenkins’ temporary folder (java.io.tmpdir), which tends to fill up rather quickly with lots of small files, especially when doing lots of maven builds.
There are lot useful plugins out there, but these are almost universal. If you do not yet use them, go ahead – give them a try!
Have I missed any important plugins? What do you think?