The Configuration Wizard is where all configuration settings can be set or altered.
The Configuration Wizard is broken up into several steps as seen above. This menu can be found at the top of every Configuration Wizard page.
The Configuration Details step contains the most basic information that is required to create a configuration, as well as some versioning settings and options.
Your configuration will be created once the details page has been saved. All other information in the Configuration Wizard will then be applied to your newly created Configuration
The Configuration Name is used to identify the configuration. Each configuration name must be unique and should reflect the task that it will be responsible for building.
It can start with a letter, number or underscore, the rest of the name can contain letters, numbers, spaces, dashes or underscores.
The Description is there to provide a brief explanation of your Configuration. This will be displayed on the configuration view page.
Only enabled configurations can run builds. Disabling a configuration will prevent this configuration from running any builds until it is re-enabled.
Versioning can be applied either at project level or configuration level. If project-wide versioning has been enabled, this will be shown in the heading for the Versioning section. You can then tick 'Set configuration-specific versioning' to override all the project versioning settings. There is also an option to override the version format string only, keeping the project-wide version counter.
Note that project-wide versioning and build number reuse is only available from version 1.7
The version counter is a numeric value which is incremented by one every time the Configuration is built.
This can be considered an offset for any builds created with this Configuration. For example, if you set the Version Counter to 50 then the first build will be version 1.0.0.50, the second build will be 1.0.0.1, etc.
By default this is set to 0.
Ticking the "Reuse build number if previous build was discarded, stopped or failed while initialising" checkbox will cause the version counter to be decremented if a build was discarded by a configuration condition, or was stopped or failed while initialising.
The build number will not be decremented if the build failed or stopped while it was queued or running. It will also not be decremented if the version counter has been incremented by another build for this configuration which has started in the meantime.
The Version Format String sets how each build should display its version. For example, the default Version Format String is set to 1.0.0.$Build.BuildNumber$ (The $Build.BuildNumber$ expression will substitute for the Version Counter value at runtime). This means that all builds for this configuration will have the following versioning:
Say you are about to start work on version 1.1 of your project. All you would need to do is set your Version Format String to 1.1.0.$Build.BuildNumber$ which will then produce the following versioning:
Expressions and Variables can be used in the Version Format String. This allows you to include dynamic values into your versioning.
You can specify which start build buttons are displayed and the default build settings here
You can choose to disable the queue build button. This will ensure users always use the quick start build button on this configuration and run builds with the default options.
You can choose to disable the quick start build button. This will ensure users always use the queue build button on this configuration and can see all options and variables.
Specify whether builds on this configuration will, by default, list all changesets since last successful build or only the latest changeset
You can choose to switch off repository checking when a build is manually started. This is useful if you know that you already have the latest changeset and want to speed up build initialisation
Note that this option only available from version 1.7
The Repositories step allows you to link Version Control Systems to the current configuration. Head over to the Repositories page for more information on creating and editing repositories.
The Variables step allows you to create and edit configuration variables. The Variables page includes an in depth guide to variables.
The Stages step allows you to specify stages, all the build actions and build workflow for this configuration.
Triggers automate build execution. Check out the Triggers section for more information.
Conditions allow you to specify whether a build should be run or when it should be executed. The Configuration Conditions section has more information.
This step allows you to specify configuration specific security settings. The Managing Security section contains all information regarding user security.
The Reports step allows you to link reports (such as unit test reports or code coverage reports) to each of your builds. The Reports section contains all reports related information.
The Cleanup policy step allows you to specify how older builds should be cleaned up for this configuration. This overrides global and project level cleanup policies. See the Cleanup section for more information.