In addition, Jenkins will never delete the last stable and successful builds, no matter how old they are.
For example, if you limit Jenkins to only keep the last twenty builds, and your last successful build was
thirty builds ago, Jenkins will still keep the successful build job as well as the last twenty failing builds.
You also have the option to disable the build. A disabled build will not be executed until you enable it
again. Using this option when you create a new build job is quite rare. On the other hand, this option
often comes in handy to temporarily suspend a build during maintenance work or major refactoring,
when notification of the build failures will not be useful for the team.
5.3.2. Advanced Project Options
The Advanced Project options contains, as the name suggests, configuration options that are less
frequently required. You need to click on the Advanced button for them to appear (see Figure 5.4, “To
display the Advanced Options, you need to click on the Advanced button”).
Figure 5.4. To display the Advanced Options, you need to click on the Advanced button
The Quiet Period option in the build job configuration simply lets you override the system-wide
quiet period defined in the Jenkins System Configuration screen (see Section 4.3, “Configuring the
System Environment”). This option is mainly used for version control systems that don’t support atomic
commits, such as CVS, but it is also sometimes used in teams where developers have the habit of
committing their work in several small commits.
The “Block build when upstream project is building” option is useful when several related projects are
affected by a single commit, but they must be built in a specific order. If you activate this option, Jenkins
will wait until any upstream build jobs (see Section 5.5, “Build Triggers”) have finished before starting
this build.
For instance, when you release a new version of a multimodule Maven project, version number updates
will happen in many, if not all, of the project modules. Suppose, for example, that we have added a web
application to the Game of Life project we used in Chapter 2, Your First Steps with Jenkins, setting it up
as a separate Maven project. When we release a new version of this project, both the core and the web
application version numbers will be updated (see Figure 5.5, “The “Block build when upstream project
is building” option is useful when a single commit can affect several related projects”). Before we can
build the web application, we need to build a new version of the original Game of Life core module.
However if you had a separate freestyle build job for each module, then the build jobs for both the core
and the web application would start simultaneously. The web application build job will fail if the core
build job hasn’t produced a new version of the core module for it, even if there are no test failures.
To avoid this issue, you could set up the web application build job to only start once the core build
has successfully terminated. However this would mean that the web application would never be built if