The dependency proxy API skeleton for Maven packages
📻 The dependency proxy API
The idea here is to let Maven Repository clients access the dependency proxy url to pull packages.
The endpoints should look for the package in these sources:
- the project's package registry.
- if not found, use workhorse's send_dependency to contact the external registry.
For the actual endpoint, we will have a single one at the project level:
- url:
/api/v4/projects/<project_id>/dependency_proxy/packages/maven
. So very similar to the project level endpoint but there is adependency_proxy
part that allow use to have dedicated routing for the dependency proxy. - For the class itself, we can use GrapeAPI as usual. The difference here is that we need to instruct workhorse to download a resource from an url and tee that into the client of the current request and upload it to a given upload url (which will be the project level Maven upload endpoint). For this complex operation, a helper function already exists but it will need an update (see below).
- We will have tracking events (similar to the ones for the dependency proxy for container repositories):
pull_package
andpull_package_from_cache
. - When locating the package, follow the logic of the existing Maven Repository download endpoint:
- locate the package
- if found, search the package file within that package.
- if not found, build the headers+url and call the external registry using workhorse's
send_dependency
.- For the upload url, target the project's level maven package registry (upload endpoint).
- This change is for GitLab Ultimate. As such, this is a new EE feature that needs to be introduced. Moreover, that feature only exists for EE: it's a EE-only feature.
- We will thus have some guards that will check the license plan. The best place for those guards seems to be the APIs.
- https://docs.gitlab.com/ee/development/ee_features.html#implement-a-new-ee-feature
- https://docs.gitlab.com/ee/development/ee_features.html#ee-only-features
For permissions, we can re-use read_dependency_proxy
. We will need to grant this permission to users that can publish packages (write_package
). So users will need to be at least developer
.
- This one will be used in the dependency proxy endpoint.
Regarding authentication, we will follow what we have for the Maven package registry and support:
- the personal access token.
- the deploy token.
- the ci job token.
For the transport of those tokens, we will again support what we support in the Maven package registry:
- custom http header.
- basic auth.
For authentication configuration, it is strongly suggested to use authenticate_with
(example)
🔭 The Plan
From the investigation:
- Database model for the dependency proxy settings (#410714 - closed).
- The dependency proxy API skeleton for Maven packages. (
👈 this issue) - The Maven dependency proxy API: cache hit path (#410717 - closed).
- The Maven dependency proxy API: cache miss path (#410719 - closed).
- The dependency proxy settings GraphQL API (#410725 - closed).
- Dependency proxy for Maven: frontend changes (#410726 - closed).
- (Option) Dependency proxy for Maven: the prefill option (#410730).
- Document the dependency proxy for Maven (#410731 - closed).
Edited by David Fernandez