The Jenkins UI can also be tailored to help in managing installations that require a large numbers of Slave hosts. This may be required to improve the performance of builds or test runs by distributing the load to other systems, or wherever Jenkins is used to perform functions spanning a multiple-host Operating System—something that Jenkins can do very easily through the built-in JNLP functionality.

Often, testing requirements dictate that a wide variety of different nodes running varying combinations of OSes and software are essential—this is common when you have an application that needs testing on different versions of Internet Explorer; each version requires a different Windows host, as each host can only support one version of the browser at a time.

Managing multiple and varying Slave Nodes can be problematic; however, the Jenkins UI provides several features that can help to simplify and automate this aspect.

One of the simplest...

Customizing and automating the Jenkins user interface can help and empower users of your Jenkins instance to help themselves.

By ensuring that it is possible only for your users to input valid data, we can greatly reduce the risk of invalid input and the resulting issues, which should improve the user experience too.

The most common way to do this is to validate the user input at runtime. For example, if your job prompts the user to enter a day of the week or a build number, you may assign this to a variable called something like $WEEKDAY or $MY_BUILD_NUM respectively.

We can then set up our job to ensure that the supplied user data is valid—if the value of $WEEKDAY is not a valid day of the week, or the user has supplied the build number as Build Two instead of an integer value that we may have been hoping for, we can cause the build to fail with an error message explaining what the user has done wrong and how to...

Sometimes Jenkins is set up and then left running in the background doing its thing; it's rarely checked upon or looked at unless things go wrong, and users are happy that things get done.

On other occasions, the Jenkins UI is used heavily by many people at the same time, all of whom will inevitably have their own requirements and priorities, and then the look and feel of Jenkins becomes a high priority.

There are many ways in which you can give the users what they want, including setting up numerous views, each providing a different user or group with a view of the (Jenkins) world that suits them.

Using the simple .*job.* regular expression ensures that all jobs (both present and future) that contain the string "job" in their title will be displayed on this view. Again, this really relies on a decent naming convention being followed, but if this is done, it can reduce the maintenance requirements of this aspect to nothing—when a...

In this chapter, we looked at the ways in which the user interface can be altered to suit your requirements. We looked at a few common issues and reviewed some possible approaches that could be used to alleviate them.

As you have seen, the Jenkins user interface is extremely powerful, and much of this power comes from its flexibility and extensibility.

Adapting the Jenkins user interface to address whatever use case applies to your environment can make a massive difference to the success of your Jenkins installation. At the same time, it also makes the user experience much more positive and can guide your users to interact with Jenkins in a mutually beneficial way. When it's easy for people to find what they want and hard for them to make mistakes (for example, due to runtime validation, dynamically populated forms, and automatically-created suites of jobs), you should have happier users and a more robust and efficient Jenkins too.

The in-built functionality of Jenkins can often...