h3. Scenario
In a continuous integration environment, it is important that builds can run as frequently as possible. A server could be configured with dozens of projects, with each project having several branches, with each branch having dozens of developers committing their code and requesting verification builds. This could impose a heavy load on the build server if all builds are executed on the single machine.
h3. Solution
You can delegate build jobs from server to agents by running build steps only on the agent nodes. Let's take a typical build process for example, it has four steps, _checkout_, _build_, _publish_, and a _default_ step to execute the other steps sequentially. By default, all three steps have property _node match condition_ being set to following value:
{code}
current.parent==null?node.isServer():(node==current.parent.node)
{code}
This means that if the step does not have parent (in the case of the master step), it should be run on the server node; otherwise, it should be running on the same node as its parent node. The effect is that all steps are by default executed on the server node. To make all steps running on the agent nodes, just set the _node match condition_ of the _master_ step to be:
{code}
node.isAgent()
{code}
Other steps remain unchanged. When build starts, the master step will try to look for a compatible node available for execution. In this case, all agents are compatible, and one of the agents will be selected based on a load balancing algorithm. All other steps will use the same agent as the _node match condition_ tells them to use the same node as their parent step.
In a real environment, it is possible that not all agent nodes are compatible with the build, and you can adjust the _node match condition_ of the master step to filter off incompatible nodes. For example by using the expression _node.isAgent() && (node.getAttribute("os.name").startsWith("Linux") \|\| node.getAttribute("os.name").startsWith("LINUX"))_, which only accepts Linux agents.
In a continuous integration environment, it is important that builds can run as frequently as possible. A server could be configured with dozens of projects, with each project having several branches, with each branch having dozens of developers committing their code and requesting verification builds. This could impose a heavy load on the build server if all builds are executed on the single machine.
h3. Solution
You can delegate build jobs from server to agents by running build steps only on the agent nodes. Let's take a typical build process for example, it has four steps, _checkout_, _build_, _publish_, and a _default_ step to execute the other steps sequentially. By default, all three steps have property _node match condition_ being set to following value:
{code}
current.parent==null?node.isServer():(node==current.parent.node)
{code}
This means that if the step does not have parent (in the case of the master step), it should be run on the server node; otherwise, it should be running on the same node as its parent node. The effect is that all steps are by default executed on the server node. To make all steps running on the agent nodes, just set the _node match condition_ of the _master_ step to be:
{code}
node.isAgent()
{code}
Other steps remain unchanged. When build starts, the master step will try to look for a compatible node available for execution. In this case, all agents are compatible, and one of the agents will be selected based on a load balancing algorithm. All other steps will use the same agent as the _node match condition_ tells them to use the same node as their parent step.
In a real environment, it is possible that not all agent nodes are compatible with the build, and you can adjust the _node match condition_ of the master step to filter off incompatible nodes. For example by using the expression _node.isAgent() && (node.getAttribute("os.name").startsWith("Linux") \|\| node.getAttribute("os.name").startsWith("LINUX"))_, which only accepts Linux agents.