The background execution of cleanup policies for container images has gone through a heavy refactoring with the main goal of conserving resources on the backend side. In other words, we put some limits on how many policies we execute in parallel and how much work load from those policies we accept. For way more details, see #208193 (closed).
We choose to use a feature flag by default as self-managed instances can have a rather different set of conditions for cleanup policies (for example, by using a third party container registry and thus not have all the bells and whistles that we have in the GitLab Container Registry). The feature flag will act as a safety net so that they can revert back to the previous behavior if necessary.
After 1 milestone and with no feedback, we will properly remove the feature flag from the code base.
Here is the rollout issue: [Feature flag] Rollout of `container_registry_e... (#238190 - closed)
🔍 What does this MR do and why?
- Update the related documentation
🖼 Screenshots or screen recordings
n / a
⚙ How to set up and validate locally
- Have a local GDK running with the container registry enabled
- Access the admin area:
<gdk host name>/admin/application_settings/ci_cd#js-registry-settings
With the feature flag enabled (
Feature.enable(:container_registry_expiration_policies_throttling)), we can see the cleanup policies throttling parameters.
With the feature flag disabled (
Feature.enable(:container_registry_expiration_policies_throttling)), we can't see them.
For a more complete test with actual cleanup policies, see !69459 (merged).
🚥 MR acceptance checklist
This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.
I have evaluated the MR acceptance checklist for this MR.