Artifact Storage Pipeline: Mermaid Flowchart

Artifact Storage Pipeline flowchart diagram

About Source

An artifact storage pipeline manages the lifecycle of build outputs — capturing, versioning, scanning, and distributing binaries, container images, and packages so every environment deploys exactly the artifact that was tested.

How the pipeline works

Once a Build Pipeline produces a validated artifact, the artifact storage pipeline takes ownership. The first step generates a unique version identifier, typically combining the semantic version with the short Git commit SHA to produce an immutable label like v1.4.2-a3f9b1c.

The artifact — whether a Docker image, JAR, npm package, or ZIP archive — is then uploaded to the appropriate registry. Container images go to a container registry (Docker Hub, Amazon ECR, GCR); library packages go to a package repository (Nexus, Artifactory, npm private registry). Metadata is written alongside the artifact: build timestamp, source commit, pipeline run ID, and the name of the signing key used to attest the artifact.

After upload, the pipeline records the artifact's cryptographic digest (SHA-256) and stores it in a release inventory. This inventory is the authoritative source of truth for the CD Pipeline, which queries it to find the correct artifact for each target environment.

Retention policies govern how long artifacts live. Artifacts promoted to production are retained indefinitely (or per compliance requirements). Untagged development artifacts are garbage-collected after a configurable window (e.g., 30 days). The pipeline enforces these policies on each new upload, pruning stale artifacts to manage storage costs.

Frequently asked questions

An artifact storage pipeline manages the lifecycle of build outputs — capturing, versioning, scanning, and distributing binaries, container images, and packages so every environment deploys exactly the artifact that was tested.

Each artifact is tagged with an immutable identifier combining the semantic version and the short Git commit SHA (e.g., `v1.4.2-a3f9b1c`). Its cryptographic digest (SHA-256) is recorded in a release inventory, making every artifact traceable to its source commit and build run.

Retention policies should be configured from the start of any project using a container registry or artifact store. Without them, storage costs grow unbounded and old artifacts accumulate — creating security risk if they contain unpatched vulnerabilities.

mermaid

flowchart TD
    BuildArtifact[Receive build artifact] --> GenerateVersion[Generate version label SHA plus semver]
    GenerateVersion --> Upload[Upload artifact to registry]
    Upload --> WriteMetadata[Write build metadata to artifact]
    WriteMetadata --> ComputeDigest[Compute SHA-256 digest]
    ComputeDigest --> StoreInventory[Record artifact in release inventory]
    StoreInventory --> PromoteGate{Promoted to production?}
    PromoteGate -->|Yes| RetainLong[Apply long-term retention policy]
    PromoteGate -->|No| RetainShort[Apply short-term retention policy]
    RetainLong --> Done[Artifact available for deployment]
    RetainShort --> GCCheck{Retention window expired?}
    GCCheck -->|No| Done
    GCCheck -->|Yes| GarbageCollect[Delete stale artifact]