Enable dependency proxy per group by default
Problem to solve
The Dependency Proxy allows users to reduce risk and reliance on external dependencies by caching frequently used packages for fast, reliable access. Currently the feature is enabled by default at the instance level, but must be manually enabled at the group level. In order to drive adoption and help users take advantage of the benefit of proxying and caching their Container Registry, we will enable it by default at the Group level.
- Drive adoption and usage of the dependency proxy, so that we can iterate and continue to improve this important feature.
- Drive adoption of the container registry and help our users to decrease the average build time for their CI/CD pipelines.
- A user connects to the GitLab Container Registry by building and pushing their first image.
- The dependency proxy is enabled
- All blobs are added to the proxy and available at the group level for future access
We will enable the dependency proxy by default at both the instance and group level. This means that the on/off button is by default, set to 'on.'
- For new groups and projects, the first time a user pull an image through GitLab Dependency Proxy, the dependency proxy will be enabled and start caching the blobs.
- For existing groups and projects, the next time a user pushes an image, the dependency proxy will be enabled and start caching the blobs.
enabled: trueon first request via UI or docker cli
- Currently we only support the Docker Registry, so by default we will set the URL to https://instance/group/dependency_proxy/containers.
- In the future, will support a unique URL per registry type. (alpine, quay, etc)
Permissions and Security
We should follow the same permissions we do for the Container Registry. Reporters and above can view the proxy but only developers and above can push and edit. For now, edit means the ability to turn the feature on and off.
|View the Dependency Proxy page, URL and # of items cached||x||x||x||x|
|Toggle the dependency proxy 'on/off'||x||x||x|
- Unicorn support: This will allow for rollout to a broader audience
- Authentication: so we can support private projects
- Purge cache functionality
- Add limits to dependency proxy
- Add ability to delete items from the proxy
- Add ability to search the proxy
Links / references
- Test functionality for new and existing groups
- What happens for instances that do not have Puma enabled?
What does success look like, and how can we measure that?
Success looks like we continue to roll out broader support for the dependency proxy. Although, it is currently limited to users that have their own instance of GitLab and have implemented Puma, this is a big first step towards increasing the awareness and adoption.
We do not currently have the ability to track this data, however gitlab-ce#61583 will help us to start tracking and measuring this data so we can make better predictions about usage and adoption.