Jenkins / Execution and source foundations / Lesson 4
Agent labels, workspace paths, and tool assumptions
Make filesystem and executable prerequisites explicit across stage allocations.
On this page
Lesson goals
- Explain why a label does not guarantee tools or clean state.
- Distinguish workspace-relative paths from controller-side files.
A label describes selection, not a complete environment
An agent label can describe a platform or capability chosen by the Jenkins owner. It does not automatically install a compiler, pin its version, clean the workspace, or prove least privilege. Parcel’s linux-lab label is synthetic and has no live node behind it. A real job should declare the relevant toolchain and verify its availability through the approved environment setup. When a command is missing, changing to a more privileged node is not a diagnosis. Identify whether selection, setup, path resolution, or executable compatibility failed.
Workspaces are allocated state
Jenkins allocates workspace directories for file-oriented execution. Concurrent runs can receive distinct directories, and different nodes have separate filesystems. Never infer a fixed absolute path from one observed run or assume a later stage on another agent sees earlier output. A reused workspace can also contain stale files unless the checkout and cleanup contract handles them. Keep cleanup narrowly scoped to owned disposable content; a public course must not prescribe broad filesystem deletion. Artifact identity should survive the worker, while intermediate workspace state may not.
Use Pipeline workspace operations at the right boundary
The dir step scopes file operations inside a relative directory on the allocated node. It does not move the controller’s process directory or install anything. The fragment below assumes a workspace and an existing fixture directory containing a complete check program. A node or stage-level agent context must surround it. Keep action at the owner’s authorized execution boundary; this illustration is not submitted to Jenkins. A controller-local File object would address another filesystem and should not replace Pipeline workspace steps.
dir("fixture") {
echo "Checking a declared fixture directory"
sh "python check_fixture.py"
}
The example requires a Unix-like authorized agent, Python, and fixture/check_fixture.py. None is provisioned or executed. The current directory change is scoped to the body, and success is not asserted without a real run.
Record the toolchain that affects output
A tool name in Jenkins configuration is an installation-specific alias whose implementation and availability must be reviewed. Agent images can change even when the label stays fixed. Capture versions or immutable environment identities that influence a candidate, but avoid printing the full environment or configuration. Separate build tools from runtime tools and account for architecture and native dependencies. A successful local build proves little about a remote agent if the required interpreter, locale, paths, or dependency resolution differ. Reproducibility requires declared inputs, not just a familiar machine name.
Detect a missing declared input without touching Jenkins
The complete local model below checks an in-memory manifest of available paths against the files a packaging stage requires. It demonstrates explicit input validation and missing-file reporting. It does not inspect an actual workspace, apply filesystem permissions, or model case behavior on every operating system. A real file check must occur on the intended agent with the intended revision and paths. If the required output belongs to another stage, fix its production and transfer relationship rather than relying on a stale file that happens to exist.
available = {"fixture/check_fixture.py", "reports/unit.xml"}
required = {"fixture/check_fixture.py", "dist/parcel.zip"}
missing = sorted(required - available)
print(missing)
print("ready" if not missing else "blocked")
['dist/parcel.zip']
blocked
The strings are synthetic manifest entries. No directories are listed or changed, and no file existence claim is made about any Jenkins agent.
Common errors and fixes
A package works only on one reused workspace.
- Why it happens
- An undeclared stale file supplies required input.
- How to fix it
- Produce and transfer the input explicitly, then validate a clean disposable path.
- Prevent it next time
- Treat required files as declared stage inputs rather than incidental local state.
A Groovy File read cannot find an agent file.
- Why it happens
- Controller-side Groovy filesystem access was confused with node workspace access.
- How to fix it
- Use the supported Pipeline workspace operation in an allocated context.
- Prevent it next time
- Document which machine owns every path and file operation.
A stable label is claimed to pin a compiler version.
- Why it happens
- Routing metadata was substituted for toolchain identity.
- How to fix it
- Record and establish the actual tool version through reviewed setup.
- Prevent it next time
- Review agent image and tool alias changes as build-input changes.
Check your understanding
1. Stage A builds on linux-lab and stage B packages on another node with the same label. Is the binary automatically present?
Show worked solution
No. The same label can match different nodes and workspaces. Transfer the declared output through an appropriate mechanism and verify its producer identity. Do not depend on accidental node reuse or a shared absolute path.
2. Why not fix a missing executable by granting administrator rights?
Show worked solution
The failure may be tool installation, PATH, architecture, or the selected environment. More authority does not establish the intended executable and can widen risk. Resolve the declared setup contract with the platform owner and keep the execution identity minimal.
Key takeaways
- A label routes work; it does not define every prerequisite.
- Workspace inputs and toolchain identity must be explicit.