AnthillPro can not find an agent to execute this job on. There are a few possible causes. The first thing to check is whether the agent you want the build to run on is, installed, online and available. The Agent should appear as Online in the current activities tab, and there should not be a warning about it being an old version on the Dashboard. Also make sure that the agent is part of the appropriate server group. For many builds, this will be the Build Farm. This can be confirmed in the Agent menu item on the System tab.
If the Agent appears to be OK, the problem is probably that the the build workflow has criteria selected with it that prevent the job from selecting this agent. Check the agent filters on any quiet period checkers as well as on the activity configuration to see if they have rules that would exclude any agents. If all else fails, contact Urbancode support
There were a number of reasons build tracks were a pretty bad idea. They have been replaced by ">living builds in the full version of AnthillPro 3. The secondary processes run in various build tracks are often better modelled as promotions and deployments.
For users of the the BMS solution, build tracks are best converted into a seperate build workflow within each project for each build track. A single build job can often be used by all the workflows with a second generic job used to manage the secondary processes. That's at least a minor improvement on the build track model.
The machine that is used for a build or deployment is selected using two controls. The first is the environment selected for running a workflow. A build will typically be run on a group of servers labelled as the build farm. You may have several build farms to support different teams. Deployments and promotions are often run on QA or Production servers which will be configured as a different "> Environments.
Once the group of servers is selected by the workflow, individual jobs (sequences of steps) are distributed to machines based on the criteria entered on the "> Agent Filter tab on the job configuration. This can restrict the job to run on a specific machine, or based on rules like operating system type, or limit the job to run on a machine where some special software is installed.
A living build breaks with the common notion that a build is a single event in time - that a build is started at one instant and ends a few seconds, minutes or hours later. Instead the AnthillPro model embraces the notion that hours, days, or weeks after the initial build, a team may want to revisit that build and run additional tests, deployments or promotions on that build. In that sense, it remains alive and active. A 'Build Life' would be the history or (more blandly) the bill of materials for given Living Build encompasing all the reports, status histories, and auditing.
For more information, see the concepts ">documentation.
'Stamp' is a generic name for build number, build identifier or version number. Often, a release ready build number isn't known at build time for various reasons, so a place holder number is used first. Later, a release style stamp can be applied. Any build life in AnthillPro 3 can have multiple stamps.
Ideally a branch build can use the same build processes (jobs) that the mainline build uses. In this case, the best way to add a branch build is to create a new source configuration in the existing project. This source configuration will point at the new branch. Then create new originating workflow that couple the new source configuration with the old job setup. More likely than not, you'll also want to add a new stamping strategy to give the branched builds distinct numbers.