Latest successful build
<server-url>/job/<build-job>/lastSuccessfulBuild/artifact/<path-to-
artifact>Latest completed build
<server-url>/job/<build-job>/lastCompletedBuild/artifact/<path-to-
artifact>This is best illustrated by some examples. Suppose your Jenkins server is running on http://
myserver:8080, your build job is called game-of-life, and you are storing a file called
gameoflife.war, which is in the target directory of your workspace. The URLs for this artifact would
be the following:
Latest stable build
http://myserver:8080/job/gameoflife/lastStableBuild/artifact/target/
gameoflife.warLatest successful build
http://myserver:8080/job/gameoflife/lastSuccessfulBuild/artifact/
target/gameoflife.warLatest completed build
http://myserver:8080/job/gameoflife/lastCompletedBuild/artifact/
target/gameoflife.warArtifacts don’t just have to be executable binaries. Imagine, for example, that your build process involves
automatically deploying each build to a test server. For convenience, you want to keep a copy of the
exact source code associated with each deployed WAR file. One way to do this would be to generate the
source code associated with a build, and archive both this file and the WAR file. We could do this by
generating a JAR file containing the application source code (for example, by using the Maven Source
Plugin for a Maven project), and then including this in the list of artifacts to store (see Figure 5.35,
“Archiving source code and a binary package”).