h3. Scenario
In a continuous integration environment, it is important that builds being run as frequent as possible. A server could be configured with dozens of projects, with each project having several branches, with each branch having dozens of devlopers commiting their code and request verification builds. This could impose a heavy load on the build server if all builds are running on that single machine.
h3. Solution
You can shift build jobs from server to agents by running steps only on 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 below value:
{code}parent==null?node.isServer():(node==parent.node){code}
This means that if the step does not have parent (in case of the master step), it should be run on the server node; otherwise, it should be running in the same node as its parent node. The effect is that all steps are by default running on the server node. To make all steps running on agent nodes, just set the _node match condition_ of the _master_ step to be:
{code}node.isAgent(){code}
Other steps remains unchanged. When build starts, the master step will try to look for a compatible node for executing. In this case, all agents are compatible, and one of the agent will be selected based on 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 uncompatible nodes, for example, the expression _node.isAgent() && (node.getAttribute("os.name").startsWith("Linux") || node.getAttribute("os.name").startsWith("LINUX"))_ only accepts linux agents.
In a continuous integration environment, it is important that builds being run as frequent as possible. A server could be configured with dozens of projects, with each project having several branches, with each branch having dozens of devlopers commiting their code and request verification builds. This could impose a heavy load on the build server if all builds are running on that single machine.
h3. Solution
You can shift build jobs from server to agents by running steps only on 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 below value:
{code}parent==null?node.isServer():(node==parent.node){code}
This means that if the step does not have parent (in case of the master step), it should be run on the server node; otherwise, it should be running in the same node as its parent node. The effect is that all steps are by default running on the server node. To make all steps running on agent nodes, just set the _node match condition_ of the _master_ step to be:
{code}node.isAgent(){code}
Other steps remains unchanged. When build starts, the master step will try to look for a compatible node for executing. In this case, all agents are compatible, and one of the agent will be selected based on 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 uncompatible nodes, for example, the expression _node.isAgent() && (node.getAttribute("os.name").startsWith("Linux") || node.getAttribute("os.name").startsWith("LINUX"))_ only accepts linux agents.