Add an application setting for cleanup policy caching
🦆 Context
Cleanup policies execution is done by a background job. Its execution is a quite complex logic flow as it involves some orchestration with the Container Registry.
In order to save some Container Registry requests, we used caching. We used the "shared state" redis instance to cache information of Container Image tags that we multiple times in several cleanup policies execution. Way more details in: #339129 (closed).
This caching feature was hard coded. In #346845 (closed), we suggested to open this as an additional parameter of cleanup policies executions. self-managed admins can then choose to use caching or not depending their conditions.
This MR creates a new application setting and use it to conditionally enable caching during cleanup policies executions.
🤔 What does this MR do and why?
- Add a
container_registry_expiration_policies_caching
in the application settings. Default value istrue
. - Update the Container Registry admin page to expose this application setting in the UI.
- Update the cleanup tags service to take into account this application setting when evaluating if caching is possible.
- Update the related specs.
- Update the related documentation.
- Took this opportunity to complete the Rest API documention for application settings with all the settings around cleanup policies execution.
🔭 Screenshots or screen recordings
Here is the UI in action in /admin/application_settings/ci_cd#js-registry-settings
:
💎 How to set up and validate locally
- Set up the container registry in GDK.
- Browse
<gdk_host>/admin/application_settings/ci_cd
- Under
Container Registry
you see the new optionEnable container expiration caching.
Seeing the effect of that caching is more complex but is documented here: !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.
💾 Database review
⤴ Migration up
$ r db:migrate
== 20220217100008 AddContainerRegistryExpirationPoliciesCachingToApplicationSettings: migrating
-- add_column(:application_settings, :container_registry_expiration_policies_caching, :boolean, {:null=>false, :default=>true})
-> 0.0069s
== 20220217100008 AddContainerRegistryExpirationPoliciesCachingToApplicationSettings: migrated (0.0069s)
⤵ Migration down
$ r db:rollback
== 20220217100008 AddContainerRegistryExpirationPoliciesCachingToApplicationSettings: reverting
-- remove_column(:application_settings, :container_registry_expiration_policies_caching)
-> 0.0056s
== 20220217100008 AddContainerRegistryExpirationPoliciesCachingToApplicationSettings: reverted (0.0056s)