Repositories and Package Management
Repositories and Package Management
This domain tests whether you can choose the right repository type, model package-manager resolution, and avoid resolution errors in Artifactory.
Core rules
- A local repository stores artifacts your organization owns and serves as a deployment target. A remote repository proxies an external registry and caches downloaded artifacts. A virtual repository aggregates local and remote repositories behind one URL and is read-only for deployment.
- Repository type is tied to package format: Maven, npm, Docker, PyPI, NuGet, Go, Helm, Debian, RPM, Generic, and others. The package type determines metadata, path layout, and client behavior.
- Virtual repositories resolve in the order configured. The first repository containing the requested path wins, so place trusted local repositories before remote proxies when you need deterministic builds.
- Maven repositories have release/snapshot handling and checksum policies. A release repository should not accept snapshots; a snapshot repository can. Docker repositories need a reverse proxy and, for virtual Docker, include/exclude patterns that select which image paths resolve.
Worked example
Your Maven build requests com/acme/app/1.0/app-1.0.jar through libs-virtual. The virtual repo lists libs-release-local first and maven-central second. If the jar exists in libs-release-local, Artifactory returns it and does not query Maven Central. If it is absent, Artifactory queries the remote, caches the artifact in the remote cache, and returns it. To publish the jar, the build must target libs-release-local, not libs-virtual.
Traps
Deploying to a virtual repository fails by design. Assuming a remote repository is a source of truth is wrong: it is a cache and may evict. Putting a remote before a local repo can silently serve an external artifact instead of your approved build. Changing package type after creation is not supported, so plan repository keys and formats before onboarding teams.