Quartz 5

Lab: package promotion and immutable build evidence

Properties1
tagslab, az-400, packages, artifacts

4 min read

Lab: package promotion and immutable build evidence

Outcome

Publish one disposable package, consume the exact version from a second project, and promote only that tested version. Compare GitHub Packages with Azure Artifacts rather than treating either registry as a build-artifact store.

Before you begin

Use a personal GitHub repository and Azure DevOps project. Use a harmless npm package such as @your-account/training-greeting; never publish a real organization package for this exercise. Record the commit SHA, package version, pipeline run URL, and artifact name in one release note.

Learn

Choose GitHub Packages when the package and its permissions belong with a GitHub repository. Choose Azure Artifacts when Azure DevOps feeds, upstreams, views, and build identities govern the supply chain. A feed view is a read-only sharing boundary; publishing happens to the base feed, not directly to a view. A package version identifies a dependency; a pipeline artifact identifies a particular build output. Keep both identifiers immutable and traceable to a commit.

Do

  1. Create a package.json with a scoped name and version: 0.1.0; add a one-function index.js and test. Tag the commit v0.1.0 only after the test passes.
  2. In GitHub Packages, configure the training package registry according to its package-type instructions. Publish 0.1.0, then create a second training repository that installs exactly @your-account/[email protected] and runs its test. Do not use an unbounded dependency range for this verification.
  3. In Azure Artifacts, create a private training feed. Give the pipeline build identity only the role it needs: reader for restore, publisher for the publishing pipeline. Enable a public-registry upstream only if the exercise needs it.
  4. Publish 0.1.0 to the Azure Artifacts base feed. Restore it in a consumer project. Save one upstream package through a Collaborator-or-higher identity, then confirm that a Feed Reader can restore the saved package but cannot save a new upstream package.
  5. In the feed, inspect @Local, @Prerelease, and @Release (or your renamed equivalents). Share only the tested 0.1.0 through the release view. Record the feed/view URL with the commit SHA and build run.
  6. In the CI pipeline, create a compressed build output named with an immutable identifier such as greeting-0.1.0-${BUILD_SOURCEVERSION:0:7}. Publish it as a pipeline artifact, then use that exact artifact in a promotion job. Set the project retention policy deliberately; pipeline artifacts remain subject to it.

Verify

Capture the GitHub package page, Azure Artifacts package/version and view, successful consumer restore, pipeline artifact, retention setting, and the release note that joins commit, package, artifact, and run. Explain why an artifact called latest.zip cannot prove what was deployed.

Break and fix

  1. Remove the consumer’s feed reader permission. Restore should fail with authorization evidence; restore the least-privilege reader role.
  2. Try to publish directly to a view. The operation should fail because views are read-only; publish to the base feed and promote through a view instead.
  3. Change the consumer to a nonexistent version or an incompatible major version. Diagnose resolution versus compatibility, then restore the known 0.1.0 version.

Clean up

Unpublish or delete only the disposable training package if your registry policy permits it. Delete the training feed, repository, pipeline artifacts, package tokens, and test views. Preserve only a scrubbed release-note example.

Scenario practice

  • Configure: A GitHub-first team publishes one library beside its source; a multi-project Azure DevOps organization needs curated upstream packages. Which registry and permission model fit each case?
  • Diagnose: A reader can see an upstream package but cannot restore it. Is the likely problem a missing saved copy, view permission, or package version?
  • Distinguish: Why does promoting a package through an Azure Artifacts view differ from retaining a pipeline artifact?

Sources and re-audit

Re-audit when registry permissions, views/upstreams, package lifecycle, or retention behavior changes.

azure-artifacts · semantic-versioning · pipeline-retention · All labs

Graph View

Backlinks