Concept and mechanism
The controller coordinates jobs, state, and configuration; agents execute work in contexts with their own tools and permissions. Separating these roles reduces administrative-data exposure to build code. Set zero executors on the built-in node and plan capacity on suitable agents. A free executor cannot serve every job: labels, online state, and scheduling restrictions determine eligibility. Jenkins runtime also needs compatibility across components. For the LTS 2.568.3 baseline, policy supports Java 21 or 25 for the controller, agents, and CLI. The JDK used to compile an application is a separate decision, although plugins can impose additional constraints. Record both runtime and build-tool versions.
Guided application
In a fictional fund platform, a queue for linux && oracle-client is not solved by adding Windows capacity. First inspect the expression, eligible agents, and phase where work stopped. Store the Jenkinsfile in version control to relate definition and application revision. In a Multibranch project, receiving a webhook is only one step: discovery, filters, and indexing must find an eligible branch. Record commit, pipeline version, and artifact identity for each release. Fingerprints help track file use across builds but do not replace signatures, tests, or storage. A traceable relationship lets support investigate without reconstructing history from informal names.
Growing queue with free executors: compare job requirements with eligible capacity before scaling.
Common pitfalls
Capacity as eligibility; workspace as isolation; runtime as application target; fingerprint as signature.
Related topics: Credentials and trust boundaries · Pipeline: scope, timing, and evidence · Delivery, approval, and retries
Diagnose execution context and connect each result to the revision producing it.
Reference: Controller and agent isolation · Jenkins LTS 2.568.3; Java 21 or 25 runtime