In a declarative Jenkinsfile, what is the difference between `agent any` at the top of the pipeline and `agent none`, and what must each stage do when the top-level directive is `agent none`?

## What the agent directive actually decides In declarative Jenkins pipelines the `agent` directive answers one question: on which machine, and in which workspace, does this block of the pipeline execute? Jenkins has a controller that orchestrates and a set of agents that execute; the `agent` directive is how a Jenkinsfile expresses which of those agents it wants. It is mandatory at the top level of a `pipeline { }` block — you must write something, even if that something is "nothing". ## agent any ```groovy pipeline { agent any stages { stage('Build') { steps { sh 'make' } } } } ``` `agent any` means: take any node that has a free executor and no restriction preventing this job from running there. Jenkins then does three things before the first stage runs. It reserves an executor, it creates (or reuses) a workspace directory on that node, and it performs an implicit `checkout scm` so the repository the Jenkinsfile came from is present. That implicit checkout is easy to forget, and you can turn it off with `options { skipDefaultCheckout() }`. The important consequence is duration. The executor is held for the *entire* pipeline, not just the parts doing work. If a stage sits on an `input` step waiting for a human to click Deploy, the executor and the workspace stay reserved the whole time. On a small fleet, a handful of pipelines parked on approvals can starve every other job. ## agent none ```groovy pipeline { agent none stages { stage('Build') { agent { label 'linux' } steps { sh 'make' } } stage('Approve'){ steps { input message: 'Ship it?' } } stage('Deploy') { agent { label 'deploy' } steps { sh './deploy.sh' } } } } ``` `agent none` allocates nothing at pipeline level. Each stage that needs to run commands declares its own agent, and stages that need no workspace — an `input` gate, a `milestone`, a notification built from `currentBuild` metadata — hold no executor at all. This is the standard shape for any pipeline with a human approval in the middle, and the standard shape for pipelines that build on one platform and deploy from another. The rules that follow from it are strict: - A stage with steps but no `agent` fails validation at run time. (`stage` blocks that only contain `parallel` or `stages` are the exception — the nested blocks carry the agents.) - Each stage agent gets a **fresh workspace** and its own implicit `checkout scm`. Build outputs from the previous stage are not there, because they were never in source control. Moving files between stages needs `stash`/`unstash` or an artifact repository. - Pipeline-level `post` blocks execute without a node. `post { always { sh 'cleanup.sh' } }` will fail under `agent none` because `sh` requires a workspace. Wrap it in a `node('label') { }` block, or put the `post` inside a stage that has an agent. ## Stage-level agents also work under a top-level agent A stage may declare its own `agent` even when the pipeline has one. Jenkins then allocates a second executor for that stage, on top of the one the pipeline already holds. That is occasionally what you want (a stage that must run on Windows in an otherwise Linux pipeline), but it doubles the executor cost, which is why `agent none` plus per-stage agents is the cleaner pattern when *every* stage has its own home. ## Other forms the directive takes `agent any` and `agent none` are the two built-in shorthands. The others name a target explicitly: `agent { label 'expr' }` for label routing, `agent { node { label 'x'; customWorkspace '/build/x' } }` when you need to control the workspace path, `agent { docker { image '...' } }` to run inside a container, `agent { dockerfile true }` to build that container from a Dockerfile in the repository, and `agent { kubernetes { ... } }` to get a pod per build. ## What interviewers are checking The short answer — "any means anywhere, none means nowhere" — is table stakes. What separates candidates is the follow-through: knowing that an executor is held across an `input`, knowing that each stage agent brings a fresh checkout and an empty workspace, and knowing that a pipeline-level `post` under `agent none` has no place to run a shell command.