Skip to content

Clean CI jobs for user/descendant namespaces when banning on GitLab.com

Ruby Nealon requested to merge ruby/ci-deep-clean-and-clear-ci-on-ban-gitlab-com into master

What does this MR do and why?

cc @ssichak @gitlab-com/gl-security/security-operations/trust-and-safety @gitlab-org/modelops/anti-abuse

BLUF: Clean CI usage for the banned user and/or CI usage in descendant projects of their owned groups when banning users on GitLab.com

More context in https://gitlab.com/gitlab-com/gl-security/security-operations/trust-and-safety/TS_Operations/planned/-/issues/61 (internal only). Please keep discussion of the background/context in that issue.

This change adds the same CI pipeline/schedule cancellations done when a user is blocked to when they are banned. This also introduces a new custom attribute deep_clean_ci_usage_when_banned that can be set before banning a user and will expand the scope of CI pipelines/schedules targeted to include pipelines and schedules made by other users in projects owned by a (sub)group owned by the user.

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

Edited by Ruby Nealon

Merge request reports