Overview
Project build options control various aspects of builds that do not justify their own configuration category.
Options
isolate changelists
When this box is checked, each build of the project will include at most one new change. This allows a change that breaks the build to be idenitified easily. For projects that can afford this level of isolation (i.e. where the change frequency and build times are low enough), this setting is recommended.
prompt
When this box is checked, manual triggers of the project will prompt for input before launching the build. This enables you to choose both the build revision and the values for all project properties to be used for the build. For example, you could manually set a version number for a release build.
retain working copy snapshot
When this box is checked, working copies for each build stage in the project will be captured and stored when the build completes, so that they may be browsed later. This option is unchecked by default because the cost of transferring the working copies from the agent to the master can slow a build significantly.
timeout
If you wish to apply a time limit to the build, enter a non-zero time limit in minutes in the "timeout" field. If any stage of the project takes longer than the specified amount of time to complete, the stage will be forcefully terminated and will finish in the error state. The build itself will also finish in the error state.
h3, stage failure limit
If not zero, specifies the number of stage failures that will cause the build to be immediately terminated. This is useful to abort builds that appear to have several problems already without waiting for all stages to completed.
automatically clear responsibility
When this option is turned on, the responsibility for a project will be automatically cleared when a build completes successfully. Usually responsibility is used to indicate that a user is fixing the build. Thus when the build returns to a successful status the user need no longer be responsible. If you use responsibility for other purposes, you can turn off this option to allow users to choose explicitly when responsibility can be cleared.
build id sequence leader
If selected, the chosen project's build id sequence is used to allocate ids for this project. By default each concrete project has its own build id sequence, where the id is incremented for each build. By selecting a build id leader, the leader's id sequence will be used to allocate build ids for this project. This allows a single id sequence to be shared by multiple projects. All projects with the same leader will share a single sequence, thus no two builds of those projects will use the same id.
persistent work directory pattern
Specifies a pattern for the persistent work directory for a project on an agent. This directory is used for incremental updates and builds (i.e. the clean update and incremental update checkout schemes) only. The pattern may include the following properties:
- agent.data.dir: the data directory for the agent running the build
- data.dir: the data directory for the pulse installation on the agent host
- project: the name of the project being built, encoded to form a valid file name
- project.handle: a unique id for the project being built
We recommend leaving the work directory pattern at the default unless it causes a problem. If a custom pattern is used, it must include $(project) or $(project.handle) to ensure a different directory for each project.
compress large logs
If checked, build and recipe logs that are larger than a threshold (100KB) are compressed with gzip when writing to them is complete. This helps reduce the disk space required to store build results with a lot of output.
