Container registry expiration policy: enabled by default for new projects
Problem to solve
In GitLab 12.8, we released the MVC of the Docker tag expiration policies for all new projects. However, currently, the feature is disabled by default. We should be following the Gitlab principle of 'default on', thereby helping users manage the size of the container registry.
Intended users
Further details
Path to supporting ALL projects with the expiration policies
We discussed how to best roll this feature out to all projects and have identified that we must:
- Improve the front-end to let people know that the expiration policy is enabled and will run Milestone 12.9
- Enable the feature by default for all new projects for GitLab self-managed Milestone 12.10
- Improve performance of the container repository cleanup tags service: Milestone 12.10
- Introduce throttling to prevent overloading the system for organizations using an external registry Milestone 13.0
- Expand Docker tag expiration and retention policies to all existing projects for GitLab self-managed instances Milestone 13.1
Enabling the feature for projects created prior to 12.8 for GitLab.com
For GitLab.com we can turn on the feature for all existing projects once the performance update is implemented on the container registry side of things in #208220 (closed). With that improvement, it will be safe for any instance running the GitLab's Container Registry to enable existing projects without having to worry about overloading the background cleanup jobs.
Self-managed instances using an external container registry
For self-managed instances not running the GitLab container registry, they can enable at their own risk, using the application setting. Then once throttling is added, the setting can be removed entirely and all projects can have policies regardless of when they were created without worry.
Proposal
For both self-managed instances AND GitLab.com, enable by default, the Docker tag expiration policies for all new projects, 12.8 forward.
Permissions and Security
- There are no permissions changes required for this issue.
Documentation
- There are no documentation changes required for this change.