Failing build is not what we want to have in out Jenkins, but it happens sometimes. Not always it means that something “went terribly wrong”, but it can be a temporary problem in communication with the code repository or another, not dangerous error. In such cases, it would be great if the build could be retried in an automated way. It’s possible and very simple to implement with Jenkins. Moreover, we don’t need to create a complex configuration. Everything we need is just a plugin – Retry Failed Builds plugin.
There are a lot of helpful plugins in Jenkins, and the Retry Failed Builds plugin is one of them. It allows you to simply retry failed build in Jenkins with the parameters you set. Each job can be configured in a different way, of course, so as you can see it has a normal granularity you may know from the other Jenkins plugins.
How to install
Installation is simple and looks exactly like for other plugins. You just need to go to the Plugin Manager and search for Naginator plugin. Yes, Naginator, it’s not a mistake. And please BE CAREFUL – there is a Retry Failed Builds Plugin, but it’s deprecated (what you can read on a plugin’s wiki page). The plugin doesn’t exist in the Jenkins Update Centre, but please remember that in case you want to install the plugin in another way than through the Plugin Manager. When you find a plugin, just simply mark the checkbox right to the plugin and install it.
How to retry failed build in Jenkins?
Ok, so we have a Naginator Plugin installed, Jenkins is up and ready, so we can now make a step forward and focus on configuration. It’s a very simple plugin, so configuration will be very easy and quick. Choose your job, which should be retried if it fails and open a configuration window. Go to the bottom and look at the Post-build actions section.
As you can see, you are able to add a new action – so let do that! After you click on the “Add post-build action” button, you should see a dropdown with the possible actions – we need to search the “Retry build after failure”.
When you do that, you see the new section with the configuration.
What should I configure?
Ok, so there is a very simple block, right? To be honest, you can’t do a lot of things. You have only three options to configure and two of them are just simple checkboxes/radio buttons. Easy, you just cannot do a lot of damage. But, actually, what these options do (or can do)?
Rerun build for unstable builds as well as failures – it’s very simple. You can specify if you want to retry also unstable builds, or just failed. What does “unstable build” mean? Check here.
Delay before retrying build – here you can look at the help message provided by Plugin’s Developers:
Progressively delay before retrying build. The delay starts at increment seconds and grows by increment * number of consecutive failures up to the maximum value, then remains at a maximum. For example, for an increment of 5 seconds and maximum of 90 seconds, the delay between builds will be (5, 15, 30, 50, 75, 90, 90, 90, …) seconds.
Maximum number of successive failed builds – in simple words, it’s a limit of retries. If you set this value to 3, failed builds will be retried only three times. When set to 0, there is no limit.
And that’s all. Ok, it’s not all, just kidding. 🙂
Maybe you noticed, that the Naginator plugin has an Advance section. Also, like the basic options, it’s not a complex section. The only one thing you can do here is to decide whether you want or not to specify a regular expression as a trigger for retry. It can be used – for example – to trigger retry only when the specific regexp will be found in the output of the shell script.
First, we need to know what do we want. Let assume we just want to retry failed build just once. Then out configuration can be similar to that one:
But what if we want to keep retrying for several times, but intervals between retries should take 30 seconds? Nothing easier! Take a look at this example:
And that’s all. Do you see how simple is it?