LEARN. PRACTICE. GROW.Define the decision before interpreting color
A fictional funds release requires the approved artifact, unit and integration tests, and a recoverable copy for thirty days. These are exercise conditions, not universal Jenkins or bank rules. Start by writing which evidence satisfies each condition and who can accept an exception. Overall build state is useful, but it results from pipeline design and step options. A flow can continue after a handled failure or without an expected report. The technical owner needs to explain what actually ran, against which object, and with what result before recommending operational handover.
Connect downstream work to the right run
When one job calls another, retain downstream run identity and the artifact it received. WaitForStart waits for start, not completion. Propagate false lets the caller handle the result explicitly; it does not approve downstream work. The reference documents different propagate defaults for build and waitForBuild, so intent should be explicit. In this lesson’s case, producer 410 created A, but integration 88 received B through latest. Even a genuine integration SUCCESS does not validate A. The first decision is to reconcile identity and obtain results for the approved object.
Interpret errors without losing stop intent
A command can return a nonzero code through returnStatus, leaving the script responsible for deciding. Storing the number without using it does not resolve failure. Likewise, a broad catchError needs to distinguish a recoverable failure from an interruption that should stop the flow; catchInterruptions false rethrows those interruptions. Before adjusting results to keep the pipeline running, describe the operational reason. Diagnostic collection may be needed after failure without permitting promotion. Build result also cannot be improved from UNSTABLE to SUCCESS through catchError buildResult. Retaining history prevents error handling from becoming evidence loss.
Publish tests and recognize missing evidence
JUnit publishes results produced by the test tool. Missing XML needs investigation when the suite is mandatory. AllowEmptyResults lets that absence leave build state unchanged, but it neither runs tests nor authorizes exclusion. Other options separate build and stage instability marking, so read results and configuration together. In the workshop, compare expected suites with observed suites for the same artifact identity. Distinguish missing, failed, and skipped tests. Do not silently use a count of unit tests to replace an integration suite addressing a different kind of risk.
Separate traceability from retention
A fingerprint helps connect produced and consumed files when the relevant projects record that information. Its database stores checksums and usages, not a binary copy; it also does not replace a trusted signature. ArchiveArtifacts addresses another need: retaining workspace files. If allowEmptyArchive permits zero files, its warning does not establish that a recoverable package exists. Define retention compatible with the support period and confirm a trial recovery. In an exercise where a package expires after seven days but may be needed on day twenty, perfect traceability still does not solve the missing copy.
Workshop and handover summary
Use the lab’s synthetic data to evaluate three candidates: A without integration testing, B with tests but outside authorization, and A with all suites and sufficient retention. The model applies only the stated fictional policy; it does not execute Jenkins, plugins, or deployments. Record concrete promotion blockers for each candidate. Then prepare handover containing producer run, test run, artifact identity, suites, failures, exclusions, and recoverable-copy location. Connect this evidence with decision owners and the change deadline. The final summary should let a colleague reproduce the reasoning without depending solely on a dashboard color.
LTS 2.580.1 and plugin context
The download page and changelog inspected on October 2 identify LTS 2.580.1, released on September 30, 2026. Runtime policy still specifies Java 21 or 25. Earlier course exercises retain their 2.568.3 baseline. The new LTS guide explains that some plugins already separated from core are no longer bundled in the WAR. On an installation without update-center access, prepare required dependencies explicitly before upgrading; do not assume copying the WAR includes test-publication plugins. Direct upgrades from very old versions have specific conditions. This lesson did not execute or certify that migration.
// Conceptual Jenkins Pipeline fragment; not executed by the local model.
// Validate installed plugin versions and the project's own acceptance policy.
def downstream = build job: 'integration', wait: true, propagate: false
if (downstream.result!= 'SUCCESS') {
error('Integration outcome requires review')
}
// Also verify artifact identity, mandatory suites and recoverable retention.
// A SUCCESS result alone does not establish those additional conditions.Producer 410 created A, but integration 88 tested B through latest. B’s result does not establish acceptance of A.
Common pitfalls
Confusing start with completion; ignoring result or returnStatus; accepting missing XML; treating fingerprints as a binary copy.
Related topics: Pipeline: scope, timing, and evidence · Delivery, approval, and retries · Upgrades, backups, and recovery
Promotion needs evidence for the approved artifact and explicit criteria. A green build alone does not establish those requirements.
Reference: Pipeline Build Step · Jenkins LTS 2.568.3 historical exercises; LTS 2.580.1 documentation reviewed 2026-10-02; Java 21 or 25 runtime; plugin versions require confirmation