Artifact Repositories, Nexus/Artifactory Integration, Package Promotion, Build Metadata, and Release Traceability: Concepts, Architecture, and Mental Model

1. The problem: “the build produced a file” is not a release process

Jenkins can archive files with a build, which is valuable evidence. A release organization normally also needs durable package coordinates, repository-level permissions, retention, metadata, promotion state, searchability and a stable endpoint from which downstream systems retrieve the exact bytes that passed CI.

Keep ownership boundaries explicit. Jenkins owns job/build execution and its retained run record. Nexus or Artifactory owns repository objects and repository policy. A deployment or package consumer reads repository state. A green upload step proves only that the client command succeeded according to its exit status; it does not independently prove the repository stored the intended coordinate or that a later consumer retrieved the intended digest.

2. Mental model: build once, identify, publish, verify, promote

flowchart TD
  A["Source SHA + Jenkinsfile/library ref"] --> B["Jenkins build on agent"]
  B --> C["Artifact bytes"]
  C --> D["SHA-256 + build metadata"]
  D --> E["Candidate repository coordinate"]
  E --> F["Retrieve + verify digest"]
  F --> G{"Promotion policy"}
  G -->|pass| H["Release repository / release status"]
  G -->|fail| I["Stop + preserve evidence"]
  H --> J["Consumer / deployment"]
  J --> K["Trace to job + build + source"]
  

A source SHA identifies source, a build number identifies one Jenkins execution, coordinates identify repository location, and a digest identifies bytes. Build metadata links those identities. Promotion changes repository or lifecycle state. Consumption and deployment remain separate external states.

3. Repository vocabulary

4. Jenkins archive versus external repository

archiveArtifacts is ideal for evidence tied to a Jenkins run. A repository manager is designed for package consumers and release lifecycle.

5. State ledger

6. Inspect before any repository mutation

Capture local identity first, before changing coordinates or retrying an upload.

set -euo pipefail
printf 'source_sha='; git rev-parse HEAD
printf 'job=%s build=%s\n' "${JOB_NAME:-local-lab}" "${BUILD_NUMBER:-0}"
printf 'node=%s workspace=%s\n' "${NODE_NAME:-local}" "${WORKSPACE:-$PWD}"
ls -lh dist/ 2>/dev/null || true
sha256sum dist/* 2>/dev/null || true

For a real repository, add read-only checks for repository identity, target coordinate and redeploy policy. If a release coordinate already exists, stop and compare evidence rather than overwriting it.

7. Nexus and Artifactory integration boundaries

Nexus raw hosted repositories support direct HTTP PUT to explicit paths; format-aware repositories have package-specific semantics and component APIs. Artifactory can associate files with Build-Info and promote builds by name/number to a target repository. Jenkins plugins can simplify those interactions, but plugins are privileged controller dependencies and require version/advisory/compatibility governance.

8. DevOps connection

Chapter 31 established digest-bound supply-chain evidence and the rule “do not rebuild during promotion.” Chapter 32 turns that rule into release operations: publish the verified candidate, record where it came from, retrieve and check it, promote the same bytes, and retain a trace from release back to Jenkins build and source.

Knowledge check

Answer before revealing the explanation.

Official references and version notes

Repository formats, Jenkins plugins, credentials models and promotion APIs evolve; prefer current primary documentation.

• Jenkins LTS changelog
• Jenkins Java Support Policy
• Jenkins Security Advisories
• Nexus Artifact Uploader plugin
• JFrog Jenkins plugin
• Sonatype Nexus Repository — Raw repositories
• Sonatype Nexus Repository — Components API
• Sonatype Nexus Repository — Uploading components
• JFrog Artifactory — Build-Info and build promotion
• JFrog — Jenkins integration