Figure 5.32. Reporting on test results
We look at automated tests in much more detail in Chapter 6, Automated Testing.
5.7.2. Archiving Build Results
With a few exceptions, the principal goal of a build job is generally to build something. In Jenkins, we
call this something an artifact. An artifact might be a binary executable (a JAR or WAR file for a Java
project, for example), or some other related deliverable, such as documentation or source code. A build
job can store one or many different artifacts, keeping only the latest copy or every artifact ever built.
Configuring Jenkins to store your artifacts is easy—just tick the “Archive the artifacts” checkbox in
the Post-build Actions, and specify which artifacts you want to store (see Figure 5.33, “Configuring
build artifacts”).
Figure 5.33. Configuring build artifacts
In the “Files to archive” field, you can provide the full paths of the files you want to archive (relative
to the job workspace), or, use Ant-like wild cards (e.g., */.jar, for all the JAR files, anywhere in
the workspace). One advantage of using wild cards is that it makes your build less dependent on your
version control set up. For example, if you are using Subversion (see Section 5.4, “Configuring Source
Code Management”), Jenkins will check out your project either directly in your workspace, or into a
subdirectory, depending on how you set it up. If you use a wild card expression like */target/.war,
Jenkins will find the file no matter what directory the project is located in.
As usual, the Advanced button give access to a few extra options. If you are using wild cards to find
your artifacts, you might need to exclude certain directories from the search. You can do this by filling
in the Excludes field. You enter a pattern to match any files that you don’t want to archive, even if they
would normally be included by the “Files to archive” field.