Distributed Builds

Distributed Builds

Distributed builds move execution away from the controller and place work on agents suited to each task. Static agents offer predictable capacity; elastic cloud or container agents appear on demand and can provide a clean environment for every build.

Core ideas

• Agent labels are a scheduling contract describing tools, operating systems, architecture, or trust zone.
• An ephemeral agent is provisioned for a workload and destroyed afterward, limiting persistent drift.
• Executors control concurrency per node; workload resource demand should determine the count.
• Workspaces, caches, and credentials require isolation when multiple builds share infrastructure.

How it works

Capacity planning starts with arrival rate, average duration, peak concurrency, and required platforms. Autoscaling should add enough warm capacity without overwhelming the controller or dependency services. Use different pools for trusted release work and untrusted change validation.

Configuration example

pipeline {
  agent {
    kubernetes {
      yaml '''
apiVersion: v1
kind: Pod
spec:
  containers:
    - name: builder
      image: eclipse-temurin:21-jdk
      command: [sleep]
      args: [99d]
'''
    }
  }
  stages {
    stage('Build') {
      steps { container('builder') { sh './gradlew build' } }
    }
  }
}

The sample is intentionally small. In a real installation, replace hostnames, labels, credentials, retention, and commands with reviewed values from your own platform standards.

Production guidance

• Use disposable agents and immutable tool images where possible.
• Do not mount a privileged container socket into agents running untrusted builds.
• Track queue wait, provisioning failures, executor utilization, and per-pool cost.

The chapter quiz follows this lesson and tests both terminology and safe operating choices.