CI/CD / Integration and candidate foundations / Lesson 6

Artifacts, manifests, and release identity

Move from files left in a workspace to retained candidates with verifiable relationships.

About 4 min readContent reviewed 2026-10-28

On this page

Lesson goals

Distinguish workspace files, job artifacts, caches, and release packages.
Verify a synthetic payload against a retained digest.

Choose storage by its promise

A workspace is where a job performs work; it is not automatically durable storage. A job artifact is a retained output tied to a run, often with an expiry. A cache is replaceable acceleration. A release package needs a retention and access policy suitable for promotion, distribution, and recovery. Parcel’s package must survive beyond the worker and long enough for the organization’s rollback policy. Merely uploading a file somewhere does not define who can overwrite it, how consumers identify it, or when it can disappear.

Describe relationships, not just names

A useful release manifest connects package identity, source revision, build invocation, dependency record, and required evidence. Friendly names help humans but can move: parcel-latest.zip is not an immutable identity. A cryptographic digest describes bytes, while an authenticated provenance statement can describe who produced them and from which inputs. Keep these concepts separate. A text file claiming source=main is only a claim until the consumer has a trusted way to verify its origin and bind it to the actual downloaded package.

Compare the bytes actually received

The following complete program hashes an in-memory payload twice, then changes one byte sequence. It demonstrates stable equality and detection of a different payload without printing a fabricated release digest. Real consumers must compare the downloaded artifact against an expected digest obtained through a trusted channel. If both package and digest can be replaced by the same attacker, matching them does not establish trusted origin. Hashes are useful building blocks within an authenticated release process.

python Detect a changed synthetic payload

import hashlib
payload = b"parcel-lab\n"
expected = hashlib.sha256(payload).hexdigest()
print(hashlib.sha256(payload).hexdigest() == expected)
print(hashlib.sha256(b"parcel-lab!\n").hexdigest() == expected)

Expected output

True
False

Both comparisons are deterministic. This illustrates byte identity only; the expected value is generated locally and is not an independently authenticated release claim.

Retention is part of recovery

If the release package expires after seven days but the supported rollback horizon is thirty, the delivery process cannot fulfill its recovery promise. Test reports and provenance may need a different retention period from large intermediate objects. Decide which evidence is required to investigate an incident after the worker disappears. Restrict access to logs that may contain sensitive inputs, and avoid placing credentials in manifests. Deleting an old pipeline can remove associated evidence on some platforms, so storage cleanup must respect the evidence lifecycle.

json An illustrative relationship record

{"candidate":"parcel-lab-r7","source":"lab-r7","package_location":"reviewed-release-store","evidence_record":"lab-checks-r7"}

The values are synthetic labels rather than real URLs, commits, or hashes. A production manifest must include actual immutable package identity and an authenticated origin. This abbreviated record is not SLSA provenance and does not claim conformance.

Verify before adoption

A consumer should identify the requested candidate, obtain its authenticated metadata, verify package identity, and confirm that required policy evidence applies. Downloading the newest object by timestamp can adopt an unapproved or unrelated build. Conversely, an old retained package may be legitimate for recovery but require a separate compatibility decision. Record which package and configuration the environment actually adopts. That final observation closes the loop between a build record and runtime reality instead of assuming a successful upload completed the release.

Common errors and fixes

A release job downloads the most recent successful artifact.

Why it happens: A mutable latest selection replaced explicit candidate identity.
How to fix it: Select the intended immutable candidate and verify its evidence relationship.
Prevent it next time: Pass release identity explicitly through promotion.

Rollback fails because its package expired.

Why it happens: Job-artifact retention was shorter than the recovery contract.
How to fix it: Retain approved packages and necessary metadata for the agreed horizon.
Prevent it next time: Review cleanup against release and incident requirements.

Matching hashes are treated as trusted provenance.

Why it happens: Byte equality was confused with authenticated origin.
How to fix it: Verify metadata origin and builder policy in addition to package digest.
Prevent it next time: Document the trust channel for expected identities.

Check your understanding

1. Can a dependency cache be the only copy of a production package?

Show worked solution

No. A cache is an optimization whose loss should be harmless. Keep an identified release package in storage with appropriate immutability, access, and retention guarantees. A consumer must not depend on a cache hit for correctness or recovery.

2. A package digest matches, but the manifest names another source revision. Is adoption safe?