Skip to content
Snippets Groups Projects
Select Git revision
  • move-gl-dropdown
  • improve-table-pagination-spec
  • move-markdown-preview
  • winh-fix-merge-request-spec
  • master default
  • index-namespaces-lower-name
  • winh-single-karma-test
  • 10-3-stable
  • 36782-replace-team-user-role-with-add_role-user-in-specs
  • winh-modal-internal-state
  • tz-ide-file-icons
  • 38869-milestone-select
  • update-autodevops-template
  • jivl-activate-repo-cookie-preferences
  • qa-add-deploy-key
  • docs-move-article-ldap
  • 40780-choose-file
  • 22643-manual-job-page
  • refactor-cluster-show-page-conservative
  • dm-sidekiq-versioning
  • v10.4.0.pre
  • v10.3.0
  • v10.3.0-rc5
  • v10.3.0-rc4
  • v10.3.0-rc3
  • v10.3.0-rc2
  • v10.2.5
  • v10.3.0-rc1
  • v10.0.7
  • v10.1.5
  • v10.2.4
  • v10.2.3
  • v10.2.2
  • v10.2.1
  • v10.3.0.pre
  • v10.2.0
  • v10.2.0-rc4
  • v10.2.0-rc3
  • v10.1.4
  • v10.2.0-rc2
40 results

groups

  • Clone with SSH
  • Clone with HTTPS
  • Forked from GitLab.org / GitLab FOSS
    5912 commits behind the upstream repository.
    user avatar
    Stan Hu authored
    There are two problems in the current implementation:
    
    1. If a project is marked for deletion via the `pending_delete` flag
    and then the namespace was quickly deleted, it's possible that the
    namespace skips over that project and leaves that project in
    an orphaned state.
    
    2. Before namespace deletion, the namespace attempts to clean up
    all the relevant storage paths. However, if all projects have been
    removed synchronously, then the namespace will not be able to clean anything.
    To prevent this, we should load the paths to be deleted before
    actually destroying projects.
    
    The specs were missing this second case due to a permission issue
    that caused project removal never to happen.
    6606a450
    History