Clean up RubyGems spec files marked pending_destruction

What does this MR do and why?

When a project is deleted, a loose foreign key marks its rows in packages_rubygems_spec_files as pending_destruction (config/gitlab_loose_foreign_keys.yml, on_delete: update_column_to, target_value: 2). However, no worker was previously enqueued to remove these records or delete their artifacts from object storage.

This MR introduces Packages::Rubygems::CleanupStaleSpecFilesWorker, modeled on Packages::Npm::CleanupStaleMetadataCacheWorker and Packages::Helm::CleanupStaleMetadataCacheWorker:

  1. Adds Packages::Rubygems::CleanupStaleSpecFilesWorker including Packages::CleanupArtifactWorker.
  2. Enqueues the worker from Packages::CleanupPackageRegistryWorker#perform when Packages::Rubygems::SpecFile.pending_destruction.exists?.
  3. Declares the data retention policy in db/docs/data_retention/packages_rubygems_spec_files.yml with enforcing: true and removes the table from spec/support/database/retention-policy-missing-allowlist.yml.
  4. Adds complete unit specs and Sidekiq worker metadata.

Closes #633765

Database Query & Execution Plan

Packages::Rubygems::SpecFile.pending_destruction.any?

SELECT 1 AS one FROM "packages_rubygems_spec_files" WHERE "packages_rubygems_spec_files"."status" = 2 LIMIT 1
Limit  (actual time=3.614..3.615 rows=0 loops=1)
  Buffers: shared read=1
  ->  Index Only Scan using index_packages_rubygems_spec_files_on_project_id_and_status
        Index Cond: (status = 2)
        Heap Fetches: 0
        Buffers: shared read=1
Time: 4.163 ms (planning 0.517 ms, execution 3.646 ms, of which I/O 3.599 ms)
Edited by Pavan Kumar Sadashiv

Merge request reports

Loading
Loading