Move container registry info update logic to a separate service
What does this MR do?
This is related to #204839 (closed). We want to be able to determine the type (GitLab Container Registry or a third-party one) and the version of the container registry used by a GitLab instance in order to drive future prioritization and user-experience decisions.
As part of #204839 (closed), a rake task was added to detect the container registry type/version and persist that information in the database (!31697 (merged)). This rake task is meant to be used by the administrators of self-managed instances.
We now need to implement a periodical refresh of the stored information in order to account for a possible change of the container registry without the need for reconfiguration. This will be implement using a cron job. In order to avoid duplicated code, this MR moves the logic introduced in !31697 (merged) from the rake task to a separate service. This service is then invoked from the rake task and will be invoked from the upcoming cron worker as well.
Does this MR meet the acceptance criteria?
Conformity
-
Changelog entry -
Documentation (if required) -
Code review guidelines -
Merge request performance guidelines -
Style guides -
Database guides -
Separation of EE specific content
Availability and Testing
-
Review and add/update tests for this feature/bug. Consider all test levels. See the Test Planning Process. -
Tested in all supported browsers -
Informed Infrastructure department of a default or new setting change, if applicable per definition of done
Security
If this MR contains changes to processing or storing of credentials or tokens, authorization and authentication methods and other items described in the security review guidelines:
-
Label as security and @ mention @gitlab-com/gl-security/appsec -
The MR includes necessary changes to maintain consistency between UI, API, email, or other methods -
Security reports checked/validated by a reviewer from the AppSec team