Use case scenario 3 – helping your users through UI automation
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 correct it, rather than allowing our job to carry on regardless and letting it attempt to perform a function or create something that we know to be invalid.
It is also good practice and generally helpful for all concerned if you can let your users know what you expect—this is easily done by setting the description next to the input box like this:
At runtime, this configuration will provide the user with a description of what we would like them to enter, and by setting a default value of 0, we can give them another hint.
This Jenkins job could then check that the value of $MY_BUILD_NUM is (as we'd hoped and requested) a numerical value greater than zero and less than 101, and then we can be reasonably happy that things are ok to continue.
It is often much safer to take the next logical step and restrict the options that are left open to the users. This further reduces the risks and also makes the experience nicer for the users—they may only run certain jobs occasionally, and expecting them to remember what you want may be a bit much to ask at times. This can be achieved by presenting them with a list of valid options and ensuring that they pick one of them:
The preceding information will be presented to the user at runtime like this:
This approach should hopefully be much more robust—so long as we remember to check that the value of ${WEEKDAY} is not equal to Please Select… before we attempt to use it!
This approach can be extended further by pulling in data from other sources and dynamically building up the options that are available to the user at runtime.
Another useful and more powerful example is the ability to populate a selection list with the values derived from current Subversion Tags.
This can be done through the List Subversion Tags (and more) option for parameterized builds. This allows you to present the user with a current list of available tags to select from—as an example, these tags could be created by other Jenkins jobs and may contain a list of candidate builds that the user can select from, to have a build deployed to an environment.
Suppose you have a Subversion repository with the following structure:
https://subversionrepo/mainproject/tags/Build_12.56
https://subversionrepo/mainproject/tags/Build_14.78
https://subversionrepo/mainproject/tags/Build_18.20
In this case, the user will be presented with a drop-down menu offering a choice of one of these three builds.
The option that the user selects is assigned at runtime to the variable that you created, say $BUILD_TO_DEPLOY, and your job can then use this selection to check out the requested build and deploy it using the SVN URL combined with the user's preferred option:
https://subversionrepo/mainproject/tags/${BUILD_TO_DEPLOY}
This functionality is provided as a part of the Subversion plugin, which is now a part of the core Jenkins build.
There are many other plugins and features that you can use to structure and improve your UI experience—the built-in Jenkins Views functionality allows you to create a dynamic list of jobs matching your criteria. This can be expressed as a simple regular expression so that all the matching jobs will be presented in one view. This works especially well when combined with a sensible naming convention for jobs.
Other approaches that may improve the user experience include setting up pipelines that manage job execution and flow. By setting up processes that the user can initiate easily, which will then carry on to work through a sequence of other jobs, the user only needs to trigger the first of several actions, like knocking over a line of dominoes, rather than trigger each build after checking that the previous build has completed and checking its stated output.
This can be achieved by simply using the built-in Build other projects option under Post-Build Actions for each job to create a simple sequence. Using the various trigger options, we can fine-tune things slightly so that certain jobs will stop the process if they have an issue, or can be set to carry on regardless, if appropriate.
If you would like to add more options, there are plenty of plugins readily available to help you. The Build Pipeline plugin offers some useful features, and the Join plugin can be incredibly useful. If you would like to run multiple jobs concurrently, then wait for them to complete before continuing and triggering the next job—as ever, there's a Jenkins plugin for most occasions!