Checkpoint Lab — Tool Installations, JDKs, Maven, Gradle, Node.js, Docker CLI, and Reproducible Build Environments

1. Mission

Use one disposable Jenkins controller and agent pool to build the same tiny Java source twice. Strategy A uses an explicitly selected Jenkins/agent JDK plus Maven installation; Strategy B uses the same build JDK but the committed Maven Wrapper. Then intentionally create a Maven-selection mismatch in a copy of the lab job, diagnose it from evidence, and repair the ownership conflict.

2. Baseline assumptions

• Disposable Jenkins 2.568.3 LTS controller.
• Controller and agent Remoting runtime use Java 21 (Java 25 is also supported by this Jenkins LTS).
• Disposable Linux agent labelled lab-linux; routine builds do not execute on the built-in node.
• Synthetic repository contains a tiny Java project and reviewed Maven Wrapper.
• No real secrets or external deployment target.
• Optional Docker comparison is allowed only on a dedicated disposable Docker-capable agent and is not required.

3. Predict state changes before running

4. Strategy A — controlled platform toolchain

Create ch08-platform-tools on lab-linux. Select the named JDK and Maven tools configured for the lab. Before invoking Maven, capture:

set -eu
{
  printf 'strategy=platform-tools\n'
  printf 'job=%s\n' "$JOB_NAME"
  printf 'build=%s\n' "$BUILD_NUMBER"
  printf 'node=%s\n' "$NODE_NAME"
  printf 'source_sha=%s\n' "$(git rev-parse HEAD)"
  printf 'arch=%s\n' "$(uname -m)"
  printf 'java_home=%s\n' "$JAVA_HOME"
  command -v java
  java -version 2>&1
  command -v mvn
  mvn -B -V --version 2>&1 | sed -n '1,8p'
} | tee toolchain-evidence.txt
mvn -B -DskipTests package
sha256sum target/*.jar | tee artifact-sha256.txt

Archive toolchain-evidence.txt, artifact-sha256.txt, and the training JAR.

5. Strategy B — project-owned Maven Wrapper

Create ch08-wrapper-tools from the same source SHA and same build JDK. Do not require a Jenkins global Maven for this strategy.

set -eu
test -x ./mvnw
{
  printf 'strategy=maven-wrapper\n'
  printf 'job=%s\n' "$JOB_NAME"
  printf 'build=%s\n' "$BUILD_NUMBER"
  printf 'node=%s\n' "$NODE_NAME"
  printf 'source_sha=%s\n' "$(git rev-parse HEAD)"
  printf 'wrapper_properties_sha=%s\n' "$(sha256sum .mvn/wrapper/maven-wrapper.properties | awk '{print $1}')"
  java -version 2>&1
  ./mvnw -B -V --version 2>&1 | sed -n '1,8p'
} | tee toolchain-evidence.txt
./mvnw -B -DskipTests package
sha256sum target/*.jar | tee artifact-sha256.txt

6. Compare evidence before comparing green badges

Place both evidence files side by side. Confirm source SHA and build JDK identity. Note whether Maven versions match. Compare the JAR checksum. If the artifacts differ, do not assume a defect immediately; first identify whether timestamps, archive metadata, tool versions, dependency state, or source inputs differ. Reproducible-build techniques are project-specific and may require additional controls beyond the scope of this introductory Jenkins chapter.

7. Inject a controlled mismatch

Clone the lab job as ch08-mismatch. Alter only the Maven ownership path—for example, select a different deliberately installed training Maven or place a known alternate Maven earlier on PATH. Do not download an unknown binary from an arbitrary URL.

Before running, predict that the toolchain evidence will differ even though the source SHA remains the same. Run once and preserve the evidence.

8. Diagnose and correct

Start from the failed/different build record. Compare:

• job/build and source SHA;
• agent and architecture;
• command -v mvn or wrapper path;
• Maven/JDK version output;
• PATH/JAVA_HOME;
• wrapper properties or global tool name;
• artifact checksum and console output.

Repair by restoring one authoritative Maven strategy. Rebuild from the same source SHA and prove the intended executable/version now runs. Do not “fix” it by adding more PATH entries until the right binary happens to win.

9. Optional container strategy

If a dedicated isolated Docker-capable lab agent is available, repeat the build in a reviewed Maven/JDK image. Record both the tag and resolved digest. This is an optional architecture comparison, not a requirement for course completion.

10. Required evidence packet

• Jenkins core and runtime Java version.
• Job full name, build number/URL, cause, and source SHA.
• Agent/node label, OS/architecture, workspace path.
• Selected strategy and controller tool names, if any.
• PATH/JAVA_HOME subset and resolved executable paths.
• Exact JDK/Maven versions; Node/Docker versions only if used.
• Wrapper properties checksum or container image digest when applicable.
• Artifact filename and SHA-256.
• Mismatch diagnosis and correction note.
• Assumptions/limitations, including whether byte-for-byte artifact reproducibility was achieved.

11. Cleanup and rollback

Delete the three disposable Chapter 08 jobs and their temporary workspaces only after preserving evidence. Remove any lab-only alternate tool installation if nothing else references it. Remove optional lab containers/images only by exact identity. Leave shared controller tool definitions intact unless you created them solely for this chapter and verified there are no dependencies.

12. What this chapter adds to a production Jenkins model

You can now separate controller tool metadata from agent binaries, distinguish Jenkins runtime Java from build JDKs, choose between global tools/wrappers/images by ownership, and bind an artifact to a concrete toolchain evidence chain. Chapter 09 builds on that foundation by introducing Pipeline execution itself: Jenkinsfile identity, durable Pipeline state, nodes, workspaces, and stages.

Knowledge check

Official references and version notes

• Jenkins LTS changelog — current LTS line and tested Java configurations.
• Java Support Policy — Java versions supported for running Jenkins controller, agents, and CLI.
• Upgrade to Java 21 — controller/agent runtime inspection and migration guidance.
• Declarative Pipeline tools directive — preconfigured JDK, Maven, and Gradle tool installations and PATH behavior.
• Pipeline examples — selecting named JDK/Maven installations and recording versions.
• Using Docker with Pipeline — containerized execution environment, image selection, caching, and Docker Pipeline prerequisites.
• Docker Pipeline plugin — plugin release and compatibility information for Pipeline container steps.
• Apache Maven Wrapper and Gradle Wrapper — project-owned build-tool version selection.
• Node.js downloads and project lockfile documentation — runtime/package-manager pinning belongs with the project or build image.