Package Feeds: One Trusted Supply Route

A pantry is not the restaurant’s source-code folder

A package registry is a controlled pantry of reusable, versioned ingredients. A Git repository records how an ingredient was made. A pipeline artifact is the prepared batch produced by a particular run. Treating all three as “some files” leads to poor access and retention decisions.

Choose the registry based on supported package formats, existing tooling, access requirements, upstream strategy, and organizational governance. Do not select solely because the source repository happens to live on the same platform.

Choice	Useful fit	Verify before choosing
Azure Artifacts	Azure DevOps feeds, views, and upstream-source workflows	Package format, project scope, identity permissions, storage charges
GitHub Packages	Packages associated with GitHub organizations and delivery	Registry-specific formats, visibility, authentication, inherited or granular permissions
Pipeline artifacts	Outputs exchanged between build/release jobs	Run identity, download permission, retention

Registry behavior varies by format. Do not assume npm, NuGet, containers, and Universal Packages have identical authentication, naming, or version rules.

Follow a dependency through the feed

Suppose a booking application uses an internal validation library and approved public dependencies. A sensible Azure Artifacts design can expose one feed to developers and build identities, with approved upstream sources. When a permitted identity consumes a package from an upstream, Azure Artifacts can save it into the feed.

This improves consistency and availability, but an upstream is not a vulnerability scanner or license approval. The first consumed package may still be unsafe. Keep dependency review and scanning in the delivery path.

For supported formats, configure the package manager to use the intended feed endpoint and the provider’s recommended credential helper. Do not copy a PAT into a committed .npmrc or NuGet configuration. A package source URL and authentication secret belong in different places.

Use the feed’s Connect to feed instructions for the actual format. They supply the correct endpoint and client setup for your project, avoiding a guessed URL.

Make views express promotion

Azure Artifacts views such as @Local, @Prerelease, and @Release let consumers see selected versions. Promotion adds a package version to a view; it is not the same as rebuilding or changing that version.

For a release process:

Publish one uniquely versioned package.
Run package-consumer and security tests against that version.
Promote the same version to the intended release view.
Configure production consumers to use the approved view.

A view is not a separate feed with a wholly independent copy of the package. Its permissions deserve their own review: a permitted view can make packages available to users without direct feed access. Conversely, a view restricted to “Specific people” with nobody selected can inherit the feed’s permissions. Do not interpret an empty selection as a guaranteed deny-all policy.

Give the build the right role

Distinguish reading packages, saving upstream packages, publishing packages, and administering the feed. A build may need more than reader access to save an upstream version but does not normally need feed ownership.

In Azure Pipelines, identify the actual build service identity and project scope. Cross-project feeds can fail even though a developer’s personal restore succeeds. Test the pipeline identity, not only your own account.

GitHub Packages permissions can be repository-scoped or granular depending on the registry. A GITHUB_TOKEN may work for a package linked to the workflow repository yet lack access to another private package. Grant the intended workflow repository access and the required token permissions using the registry’s documented model.

Diagnose the failure class

Symptom	First checks
Works locally, fails in CI	Build identity, token scope, endpoint, credential helper
Package exists but is not found	Feed/view, exact version, format, package name
Restore works but publish fails	Publisher role, immutable version already present
New upstream package cannot be saved	Upstream policy and consuming identity’s role
Unexpected public dependency	Configured sources, lockfile, upstream ordering and approved source

An assistant can compare source configuration and logs, but it should not “fix” a restore by adding every public registry or printing credentials. Verify the smallest permissions change against the real failing identity.

Knowledge Check

A tested package is ready for production through an Azure Artifacts release view. What best preserves its identity?

Try it: inspect a feed as two identities

Prerequisites: a sandbox Azure Artifacts feed or GitHub registry with permission to inspect settings. Storage and CI usage can be billed; this exercise does not require publishing.

Inspect the package format, endpoint, upstreams, views, and effective reader/publisher access. Compare your account with the build identity. Write the intended path from publish to test to promotion to consumption. If publishing a harmless sandbox package, use a unique test version and verify it through the real consumer.

Expected observation: you can explain which identity reads, saves upstream versions, publishes, and promotes. These capabilities are not all implied by successful personal access.

Cleanup: remove only your test package/version if permitted and restore sandbox permissions you changed. Retention and deletion rules may prevent reusing that version; do not use a production package name for experiments.

Question

What does an upstream source not guarantee?

Click or press Enter to reveal answer

Decision check: one feed or several?

Use the smallest layout that reflects real ownership and trust boundaries. More feeds increase permissions and configuration overhead; one unrestricted feed can erase meaningful isolation.