DevOps AcademyLearn the delivery system
Chapter 32Lesson 03~180 minutes

Artifact Repositories, Nexus/Artifactory Integration, Package Promotion, Build Metadata, and Release Traceability: Configuration, Design Choices, and Tradeoffs

Design repository integration around immutable identity, trust boundaries and consumer needs; treat plugins as optional controller dependencies rather than the only automation path.

DesignNexusArtifactoryPromotionPluginsRetention

Learning objectives

  • Choose between Jenkins archives and external repositories based on lifecycle needs.
  • Separate snapshot/prerelease and release repository policy.
  • Compare server-side promotion, download/re-upload and rebuilding.
  • Keep artifact bytes immutable while lifecycle metadata changes.
  • Choose plugin, CLI or direct API integration with explicit maintenance tradeoffs.

1. Choice 1: Jenkins archive or repository?

Use the system that owns the lifecycle. Build-local evidence may follow the Jenkins run; packages used by many consumers need durable repository semantics.

Need Jenkins archive External repository
Build-local reports/evidence Natural fit Usually unnecessary unless independent retention is required
Package-manager consumption Awkward Native fit
Promotion Custom/manual Repository-native copy/move/status/build promotion
Retention independent of Jenkins Coupled to build history Separate policy
Cross-team distribution Limited Designed for it

2. Choice 2: prerelease versus release state

Candidates are numerous and disposable; releases should be stable. Separate repository classes or explicit lifecycle states let you apply different overwrite, retention and permission policies. A useful pattern is: protected-branch CI publishes uniquely versioned candidates; a distinct promotion identity changes release state only after policy verification.

3. Choice 3: server-side promotion versus republish

Pattern Strength Risk
Server-side copy/move/status Preserves repository-known identity and avoids rebuild/network round-trip. Product-specific permissions/semantics.
Download + verify + upload same bytes Portable across products and trust boundaries. More bandwidth and more selection points.
Rebuild from source Useful for separate reproducibility experiments. Wrong default for release promotion: bytes can differ.
Overwrite mutable version Convenient. Destroys auditability and can change what consumers receive.

If you perform a reproducibility rebuild, treat its result as a comparison artifact. Do not silently substitute it for the candidate that CI verified.

4. Choice 4: immutable binary, evolving metadata

Approval status, scan state or retention labels may evolve while artifact bytes remain immutable. The digest is the stable join key across Jenkins, repository metadata and downstream deployment evidence. Changing metadata must not be a hidden mechanism for replacing payload bytes.

5. Choice 5: plugin, vendor CLI, REST/API or native package client?

Integration Benefits Costs / governance
Jenkins plugin Tight Pipeline/UI/credential integration. Controller dependency, transitive dependencies, compatibility and advisories.
Vendor CLI Reusable outside Jenkins; often aligned with vendor features. Pin/verify binary; manage config and credentials on agents.
Direct REST/API Explicit small surface. You own auth, retries, idempotency, pagination and response validation.
Native package client Correct package-format semantics. Client config/credential scope; promotion may still use repository API.

At the dated baseline, Nexus Artifact Uploader 2.16 is marked “up for adoption” and requires Jenkins 2.528.3. The JFrog plugin 1.8.0 requires Jenkins 2.462.3 and wraps JFrog CLI. Those facts are dated governance inputs, not permanent recommendations.

6. Credential design

Separate identities by operation.

Identity Typical scope Untrusted PR code?
Candidate publisher Write candidate repository/path + read-back Normally no for arbitrary forks
Promoter Read candidate + release promotion/write No
Consumer Read immutable release coordinates Only where needed
Repository admin Repository creation, policy, broad delete/admin Never ordinary build code

7. Retention and cleanup are release design

Candidate retention can be short; release retention may be contractual. Metadata should survive as long as audit/recovery questions require it. Never implement cleanup as “delete latest.” Cleanup must select exact coordinates and exclude protected release state.

8. Worked scenario

  1. PR builds retain tests/reports in Jenkins but publish no release package.
  2. Protected-branch builds publish uniquely versioned candidates.
  3. Build metadata records job/build/source SHA and digest.
  4. A separate release job verifies candidate evidence with separate credentials.
  5. Repository promotion places the same bytes into release state.
  6. Deployment reads release coordinates and records the consumed digest.

The result is a continuous artifact identity with limited write authority.

9. Wrong approaches

  • Publish every build as 1.0.0 and let the latest upload win.
  • Use repository administrator tokens to avoid permission troubleshooting.
  • Rebuild in the promotion stage.
  • Keep only a filename and omit job/build/source metadata.
  • Install overlapping repository plugins without a clear configuration owner.
  • Assume 2xx upload response equals package resolvability and release acceptance.
Next

Diagnose by state transition

Lesson 4 examines overwrite, rebuild, permission, ambiguous deletion, traceability and performance failures while preserving first-failure evidence.

Knowledge check

Answer before revealing the explanation.

1. When is a Jenkins archive preferable?

2. Why separate promotion credentials from candidate upload credentials?

3. What is the release risk of rebuilding during promotion?

4. Why does plugin maintenance status matter?

Official references and version notes

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

Keep the academy open

Support free, practical DevOps education.

Every lesson is designed to remain readable in a browser, downloadable from GitHub, and usable without a paid learning platform. Contributions help expand and maintain the curriculum.

Ethereum / ERC-20
0x716c4Ab160C4B66F31a28AE2448BfF68fc3a2ef0Send only Ethereum/ERC-20 compatible assets to this address.