Page History

...

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.

Expression Logic

Specify the logical operator that should be applied to the automatic promotion conditions above.

Anchor
promoteoption promoteoption

Promote Options

...

Conditions which control automatic promotion.

Expression Logic

Specify the logical operator that should be applied to the automatic promotion conditions above.

...

See Defining Shared Resource Locks for more details on editing Stage Shared Resource Locks.

Agent Requirements

Image Removed

Agent requirements are Agent requirements are a set of conditions that must be met before the stage will execute on a particular agent. In addition to using variables as condition values, you can also use the $Agent$ descriptor which gives you access to agent details like hostname, port and all property collector values. Note that these conditions give you fine grain control over the configuration and stages. It's possible to make the entire Configuration execute on a single agent, but having agent requirements allows you to force one stage to run on a specific agent while letting Continua decide which is the best agent to run the other stages on. If the rules are left blank then Continua CI will determine which agent should run that stage.

...

• You have a trigger set up to execute every day at 3 in the morning. It executes a Configuration which is set up to take a copy of your main repository, archive it and send it to your backup server. The backup server also happens to act as a Continua CI agent and you want to take advantage of that, By using the backup server agent, the backup archive file will be created in the build's workspace on the backup server agent, then it's just a matter of copying that file from the build's workspace, into a directory on the backup server that handles backing files up. If you were to use an agent that wasn't the backup server then the copying of the archive file to the backup server would happen over the network. This is an ideal situation for an agent condition that forces a stage to run on a specific agent. To do this, you would reference the agent's hostname by using the descriptor $Agent.Hostname$ then select Equals from the drop down list and put the name of the agent in the right hand side input field.
  
  
• You've created a program or script that automates a whole lot of functionality like creating installers for your application, uploading them to a FTP server and sending out emails to your users. When you integrate it into Continua CI, you simply create a stage which has an Execute Program Action which executes your script. Because your script is creating installers, uploading files using FTP and sending out emails, your script needs to be executed on an agent that has your installer creator application, the ftp client and email application installed. To ensure the build runs on an agent with all three of those applications installed you would setup agent conditions for the stage that runs your script. First you would setup Property Collectors for each of the applications, all they would do is check if an executable exists (eg. MyFtpClient.exe) in the given path. Once they're setup, you can create an agent condition that checks for the existence of that application. You would first choose the Exist option from the drop down menu then use a descriptor like $Agent.MyFTPClient.Path$. This would force the build to only execute on an agent which has that path on it.
  
  
• You can select the agent you want a build or stage executed on when you start the build. Create a Configuration Variable called AgentToRunOn for example and make it a prompt type of Text. By doing this, every time you manually start a build, it will ask you what Text value you would like to provide to the AgentToRunOn variable. When setting up your agent conditions on a stage, you would use the $Agent.Hostname$ descriptor for the left value, select Equals from the drop down list and type %AgentToRunOn% for the right value. By doing this, you allow the user to type in which agent they want a stage run on every time a build is manually started. You could make it more secure by changing the variable to be a Selection prompt type and supply a list of agents that can be used. You would of course need to create specific permissions for editing variables and allow only admins to edit variables.

Agent Priority

The “Agent Priority” field determines the sequence in which agents with equal capacity are chosen to execute a particular stage. This field should contain a property that is unique to each agent.

By default, new stages will include the expression $Agent.Priority.Value$, which refers to an agent property collector. This collector defines a numerical "Priority.Value" property for each agent, with a default value of 0. To assign priority to an agent for this stage, modify the ‘Priority.Value’ property for that agent. If you need to set a different priority for a stage or group of stages, consider adding a new agent property collector.

The priority expression can evaluate to either a number or a string:

• If it’s a number, agents with higher numbers are prioritized.
• If it’s a string, agents are ordered alphabetically, with “A” selected before “Z”.

You can reverse this order by selecting the “Select agent in reverse order of priority” option.