this practice is to run OS-specific functional tests on dedicated slave nodes, or to reserve a particular
machine exclusively to performance tests.
Once you have assigned labels to your slave nodes, you also need to tell Jenkins where it can run the build
jobs. By default, Jenkins will simply use the first available slave node, which usually results in the best
overall turn-around time. If you need to tie a build job to a particular machine or group of machines, you
need to tick the “Restrict where this project can be run” checkbox in the build configuration page (see
Figure 11.15, “Running a build job on a particular slave node”). Next, enter the name of the machine, or
a label identifying a group of machines, into the Label Expression field. Jenkins will provide a dynamic
dropdown showing the available machine names and labels as you type.
Figure 11.15. Running a build job on a particular slave node
This field also accepts boolean expressions, allowing you to define more complicated constraints about
where your build job should run. How to use these expressions is best illustrated by an example. Suppose
you have a build farm with Windows and Linux slave nodes (identified by the labels “windows” and
“linux”), distributed over three sites (“sydney”, “sanfrancisco”, and “london”). Your application also
needs to be tested against several different databases (“oracle”, “db2”, “mysql”, and “postgres”). You
also use labels to distinguish slave nodes used to deploy to different environments (test, uat, production).
The simplest use of label expressions is to determine where a build job can or cannot be executed. If
your web tests require Internet Explorer, for example, you will need them to run on a Windows machine.
You could express this by simply quoting the corresponding label:
windowsAlternatively, you might want to run tests against Firefox, but only on Linux machines. You could
exclude Windows machines from the range of candidate build nodes by using the! negation operator: