Jenkins Pipeline docker agent and Docker daemon: image pull policy and host dependency reproducibility

Integration boundary

The agent { docker { ... } } directive in Jenkins Pipeline delegates container provisioning to the Docker daemon available on the selected agent. This creates an integration boundary between the Jenkins controller's pipeline execution model and the host-level Docker runtime, where reproducibility depends on factors outside Jenkins' direct control.

Goal and constraints

The goal is a repeatable development environment where every build uses the exact same container image and runtime characteristics regardless of which agent executes the pipeline. Current constraints include: mutable image tags (e.g., latest) resolve to different digests over time; Jenkins does not enforce --pull=always by default, so cached layers may stale; Docker daemon version, host kernel, and mounted volumes differ across agents; and the resolved image digest is not recorded in build metadata, preventing post-build audit without extra scripting. The choice between Docker-in-Docker and host socket binding further changes isolation guarantees, yet Jenkins documentation leaves this architectural decision to the user.

Questions

1. What combination of Pipeline options (alwaysPull, args, reuseNode) and agent-side daemon configuration yields deterministic image resolution across heterogeneous agents?
2. Is there a supported pattern to capture and surface the resolved image digest in the build record without custom wrapper scripts?
3. How should teams evaluate the trade-off between DinD isolation and host socket binding when organizational policy requires reproducible builds across mixed daemon versions?