...
Stage options can be accessed by double clicking on a stage arrow from the 'Stages' workflow section. A dialog showing options for the respective stage will be displayed:
Stage Options
Name
The name of the stage
Enabled
Should the stage be considered when running a build.
Skip Conditions
Conditions which result in this stage being skipped. Expressions can be used here to build up a set of conditions. Note that multiple conditions are joined together with a logical AND - as a result, if any of the lines evaluate to false, the respective stage will be run.
...
Anchor | ||||
---|---|---|---|---|
|
Always automatically promote to the next stage
Determines if this stage should be automatically promoted once it has completed executing, or if it should await manual promotion.
Once a stage has completed, the options on this tab determine whether the build automatically continues onto the next stage. If this option is not ticked the 'Auto-promote conditions' come into effect to determine if the build should continue. Please note that the Auto-promote Conditions are joined together with a logical AND. As a result, if any of the lines evaluate to false, the stage status will be set to 'Stage Pending Promotion'.
Enable stage promotion timeout
Determines how long a the build should wait for promotion to the next stage. If this is ticked then the build will be marked as completed once the Timeout Duration is reached. This will allow the build to be cleaned up, but will prevent the build from being promoted.
Timeout Duration
Length of time (in hours) this stage should await manual promotion.
Auto-Promote Conditions
Conditions which control automatic promotion.
Expression Logic
Specify the logical operator that should be applied to the automatic promotion conditions above.
Clicking on the Promote button will trigger the next stage.
...
Scenarios and examples of workspace exclude rules can be found on the Workspace Rules page.
Log workspace files copied
Write the file name of each file copied to the Build Log.
Repository Rules
A repository rule is used to get files out of the repositories attached to the Configuration and into the agent's workspace. Repository rules look and function similar to workspace rules but have a few extra constraints.
...
When a build starts and the workspace is initially created on the server, the contents of that build's workspace contain no trace of any repositories. Instead, the server will process the repository rules and determine which repositories need to be synced to the agent. The agent will then take note of those repositories and update its repository cache. The agent then runs the repository rules against the repository in its repository cache. This eliminates the need for the server to deal with any copying of repositories. It also has the advantage of making subsequent builds a lot quicker. Instead of having to copy the repository from the server to the agent for each build, the agent simply does a local copy from its repository cache into the workspace directory.
Log repository files copied
Write the file name of each file copied to the Build Log.
Artifacts
What are Artifacts?
...
Scenarios and examples of registering can be found on the Artifact Rules page.
Log workspace files copied
Write the file name of each file copied to the Build Log.
Shared Resource Locks
Info |
---|
Note that Shared Resource Locks are available from version 1.8 |
...