In the context of build promotion, a common strategy is to build your application once, and then to run
tests against the generated binary files in a series of downstream build jobs. This approach works well
with build promotion, but you need to ensure that Jenkins fingerprints the files that are shared or copied
between build jobs. In the example shown in Figure 10.43, “Configuring a build promotion process”, for
instance, we need to do two things (Figure 10.46, “Using fingerprints in the build promotion process”).
First, we need to archive the generated WAR file so that it can be reused in the downstream project.
Secondly, we need to record a fingerprint of the archived artifacts. You do this by ticking the “Record
fingerprints of files to track usage” option, and specifying the files you want to fingerprint. A useful
shortcut is simply to fingerprint all archived files, since these are the files that will typically be retrieved
and reused by the downstream build jobs.
Figure 10.46. Using fingerprints in the build promotion process
This is all you need to do to configure the initial build process. The next step is to configure the
integration tests executed in the phoenix-integration build job. Here, we use the Copy Artifact
plugin to retrieve the WAR file generated by the phoenix-default build job (see Figure 10.47,
“Fetching the WAR file from the upstream build job”). Since this build job is triggered immediately after
the phoenix-default build job, we can simply fetch the WAR file from the latest successful build.
Figure 10.47. Fetching the WAR file from the upstream build job
This is not quite all we need to do for the integration tests, however. The phoenix-integration build
job is followed by the phoenix-web build job, which executes the automated web tests. To ensure that
the same WAR file is used at each stage of the build process, we need to retrieve it from the upstream