phoenix-integration build job, and not from the original phoenix-default build job (which may
have been executed again in the meantime). So we also need to archive the WAR file in the phoenix-
integration build job (see Figure 10.48, “Archiving the WAR file for use in the downstream job”).
Figure 10.48. Archiving the WAR file for use in the downstream job
In the phoenix-web build job, we then fetch the WAR file from the phoenix-integration build
job, using a configuration very similar to the one shown above (see Figure 10.49, “Fetching the WAR
file from the integration job”).
Figure 10.49. Fetching the WAR file from the integration job
For the build promotion process to work properly, there is one more important thing we need to
configure in the phoenix-web build job. As we discussed earlier, Jenkins needs to be able to be sure
that the WAR file used in these tests is the same one generated by the original build. We do this
by activating fingerprinting on the WAR file we fetched from the phoenix-integration build job
(which, remember, was originally built by the phoenix-default build job). Since we have copied
this WAR file into the workspace, a configuration like the one in Figure 10.50, “We need to determine
the fingerprint of the WAR file we use” will work just fine.
Figure 10.50. We need to determine the fingerprint of the WAR file we use
The final step is to configure the phoenix-deploy-to-test build job to retrieve the last promoted
WAR file (rather than just the last successful one). To do this, we use the Copy Artifact plugin again, but
this time we choose the “Specified by permalink” option. Here Jenkins will propose, among other things,