Skip to content

Delayed deletion of projects by default, to avoid catastrophes

Update 11 Aug 2021:

Dev for this is complete, the remaining work is this production change request to enable the setting by default on the Gitlab.com instance: gitlab-com/gl-infra/production#5323 (closed)

Problem to solve

Projects can contain a huge amount of valuable data. Currently they can be deleted instantly. If deletion is the result of a mistake or a bug (like !40353 (merged)), it can be catastrophic.

Proposal

Turn on https://docs.gitlab.com/ee/development/cascading_settings.html at the instance level and lock it. Provide mechanisms for project owners to immediately delete projects scheduled for deletion. Allow for the immediate re-use of paths from projects that are scheduled for delayed deletion. As a bonus, explore allowing subgroups to specify the duration of the deletion period (maybe so long as it is longer than the default setting at from the parent group/instance).

Old proposal:

Hard deletion of *all* projects should be preceded by a period of delayed deletion, where the project is no longer visible to users but can be restored by admins.

This is different from, but would rely on the same functionality as, the delayed deletion setting. This would be followed by implementing similar functionality for groups.

Implementation Steps

  • #191367 (closed) : Support the ability to immediately delete a project scheduled for delayed deletion by navigating to Project > Settings > Projects and double confirming hard deletion
  • Enable the setting by default for newly created top-level namespaces.
  • Add instance setting for delayed deletion (!67230 (merged))
  • Ensure instance admins can restore any project within the instance that is scheduled for delayed-deletion.
  • Add support for Premium+ Groups to override the default delayed period set at the instance level. Subgroups should look to their nearest ancestor to get the default setting. Consider leveraging the existing work being down to cascade settings in a consistent manner (#291082 (closed))

Possible follow-ups / enhancements:

GitLab.com Rollout Steps

  • Ensure that the relevant docs section is updated.
  • Let the Support team know when it happens via #support_gitlab-com and additional details like if it's behind a feature flag, it's part of the feature flag process/template, so no additional steps are needed.

Release Post Notes

Up until now, delayed project deletion has been disabled by default on GitLab.com because there has been no way to immediately delete a project when necessary. In this release, we've added an instance setting to enable delayed deletion by default for all new projects. We've also added the ability for projects scheduled for delayed deletion to be immediately, permanently removed. Delayed project deletion is now enabled by default for GitLab.com and leverages our cascading settings framework so groups can freely opt out of the default behavior if so desired.

Documentation

Edited by Austin Regnery