Deprecate Sidekiq Cron Jobs being user-configurable
Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.
Context
Historically we exposed the configuration of Sidekiq Cron Jobs through gitlab.yml file, but the reason why this was made is unclear today.
The guess is that, at some point it was a useful tuning variable (being able to enable/disable specific optional cronjobs). I don't believe we do have those usecases in the software anymore, or if we still do, this is a really bad interface to do so.
As an example, Geo does have a way to enable/disable Cron Jobs that does not rely on gitlab.yml configuration change, See: https://gitlab.com/gitlab-org/gitlab/-/blob/56ec853193b15f7dfe65be2a805959f6ee5da304/ee/lib/gitlab/geo/cron_manager.rb#L5-5.
By making cron-jobs a machine specific configuration exposed through gitlab.yml we create a lot of complexity and the possibility of conflicts when a configuration diverges incorrectly from one machine to another.
This also makes it harder to add or remove jobs in new releases as the gitlab.yml file is exposed through multiple deployment strategies like:
- Source install
- Omnibus
- Kubernetes Operator
- Kubernetes Charts
- Docker
- Openshift !?
- Dedicated
Proposal
Remove cron_jobs and ee_cron_jobs from gitlab.yml and move those settings to a dedicated config/sidekiq_cron.yml file that is not exposed as a user configurable setting (in any of the deployment strategies above).
Doing so still gives us the piece of mind of allowing patching the cron in emergencies/edge cases while removing the burden of supporting those officially.