Context

GitLab provides audit events, which allow users to track a variety of different actions within GitLab. In Add the Package Registry to the list of audited... (#329588), it was proposed to implement audit events for the package registry. The scope of the implementation is detailed in this comment. This MR is the 2nd part of the implementation: Add audit logs for Package destruction.

What does this MR do and why?

• When a package of any format is deleted from the package registry, an audit event is created. The audit events is a GitLab Premium feature, so its code lives in the ee folder.

• In the package registry, packages are destroyed in two fashions:

  • Single package destruction through the Packages::MarkPackageForDestructionService.
  • Bulk package destruction through the Packages::MarkPackagesForDestructionService.

  In those two services, the packages' status is updated to pending_destruction, and then a background job should pick them up and call .destroy! on each package.

  So, in order to be able to send the audit event, we have to hook into each service's execute method instead of using a model's callback for two main reasons:

  • The user who is performing the destruction is a very important piece of info in the audit event, and we can have access to the current_user only in the services.
  • In the Packages::MarkPackagesForDestructionService bulk action, the packages' status update is done using .update_all, which doesn't trigger any model callbacks.

• To send audit events for the Packages::MarkPackagesForDestructionService bulk destruction, I needed to apply some changes on how we could utilize Auditable#push_audit_event to store multiple events in the ::Gitlab::Audit::EventQueue and create them in bulk. This is faster and more efficient than iterating over destroyed packages and create events one by one.

• The audit events are saved on the direct parent group. So when a package is destroyed in a project, the event will be available/visible in the parent group of the project. In case the project doesn't have a parent group (belongs to a user namespace), the events will be available in the project.

• The feature is behind a WIP feature flag package_registry_audit_events, so that we can add the rest of the implementation behind the same feature flag.

• The implementation is guided by this documentation page: https://docs.gitlab.com/ee/development/audit_event_guide/#how-to-instrument-new-audit-events.

References

Please include cross-links to any resources that are relevant to this MR. This will give reviewers and future readers helpful context to give an efficient review of the changes introduced.

• Add the Package Registry to the list of audited... (#329588)

MR acceptance checklist

Please evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.

Screenshots or screen recordings

How to set up and validate locally

Numbered steps to set up and validate the change are strongly suggested.

1. Make sure the feature flag package_registry_audit_events is enabled.
2. Make sure your GDK has an enterprise licence: https://gitlab.com/gitlab-org/gitlab-development-kit/blob/main/doc/index.md#use-gitlab-enterprise-features
3. Create a couple of packages from rails console:

   # stub file upload
   def fixture_file_upload(*args, **kwargs)
     Rack::Test::UploadedFile.new(*args, **kwargs)
   end
   
   FactoryBot.create(:npm_package, project: Project.find(<project_id>))
   
   FactoryBot.create(:generic_package, project: Project.find(<project_id>))
   
   FactoryBot.create(:nuget_package, project: Project.find(<project_id>))

4. Navigate to the group or project package registry UI page, and delete packages in bulk.
5. Navigate to the group audit events page in the UI. Each destroyed package should have an audit event on the page.

Related to #329588