Artifacts, Retention, and Fingerprints

Scenario: A deployment rebuilds the approved branch and ships bytes different from those tests validated.

Pipeline example

stage('Package') { steps { sh './package.sh'; archiveArtifacts artifacts: 'dist/*.tgz', fingerprint: true } }

Artifacts identify one build output

Release artifacts should be immutable and carry source revision, build identity, toolchain, and checksum. ArchiveArtifacts copies matched files into Jenkins build storage; fingerprint records hashes used to relate producers and consumers. Configure empty-match and success-only behavior consciously: diagnostics can matter after failure, while a release package should not appear after an invalid package stage.

Jenkins archives work well for reports and modest outputs. A binary repository offers stronger lifecycle, distribution, signing, vulnerability metadata, and access policy for releases. Do not overwrite latest as the only coordinate. Publish versioned or content-addressed bytes and maintain a separate promotion pointer.

Retain the provenance chain

Build discarders bound record and archive age; fingerprint cleanup and repository retention must align. If the producing Jenkins build expires before the product support window, durable external metadata must still connect deployed digest, source, tests, and approvals.

A promotion job accepts a digest, verifies signature and gates, and marks or copies existing bytes. It must not recompile the branch. During incidents compare deployed and tested digests; matching friendly versions prove nothing when a mutable coordinate has been overwritten.

Goal: Practice the concrete behavior in jenkins-artifact-promotion. Learn sections have no Jenkins terminal; the Jenkins lab opens the real shared service in a new full-screen tab inside your private folder.