Skip to content
Snippets Groups Projects
Select Git revision
  • master default protected
  • 12-9-stable
  • 12-7-stable
  • 12-6-stable
  • 12-8-stable
  • github/fork/Kloppi313/patch-1
  • 12-5-stable
  • 12-4-stable
  • github/fork/ramalokesh8477/master
  • 12-1-stable
  • 12-2-stable
  • 12-0-stable
  • 12-3-stable
  • 42-42-stable
  • github/fork/hussamgit398/patch-2
  • 12-3-auto-deploy-20190911
  • 12-3-auto-deploy-20190916
  • 12-3-auto-deploy-20190908
  • 12-3-auto-deploy-20190901
  • 12-3-auto-deploy-20190901-32664
  • v12.10.0.pre
  • v12.9.0
  • v12.9.0-rc42
  • v12.8.7
  • v12.8.6
  • v12.8.5
  • v12.8.4
  • v12.8.3
  • v12.6.8
  • v12.7.7
  • v12.8.2
  • v12.8.1
  • v12.9.0.pre
  • v12.8.0
  • v12.8.0-rc42
  • v12.5.10
  • v12.7.6
  • v12.6.7
  • v12.7.5
  • v12.5.9
40 results

destroy_service.rb

  • Oswaldo Ferreir's avatar
    4fd848fc
    Cleanup stale +deleted repo paths on project removal · 4fd848fc
    Oswaldo Ferreir authored
    1. When removing projects, we can end-up leaving the +deleted
    repo path dirty and not successfully removing the non-deleted
    namespace (mv process is not atomic and can be killed without
    fully moving the path).
    
    2. In order to solve that, we're adding a clean-up phase on
    ensure which will schedule possible staled +deleted path deletion.
    Note that we don't check the current state (if there is or not a
    repo) in order to schedule the deletion. That's intentional
    in order to leverage Gitlab::GitalyClient::NamespaceService#remove
    idempotency and ensure consistency.
    4fd848fc
    History
    Cleanup stale +deleted repo paths on project removal
    Oswaldo Ferreir authored
    1. When removing projects, we can end-up leaving the +deleted
    repo path dirty and not successfully removing the non-deleted
    namespace (mv process is not atomic and can be killed without
    fully moving the path).
    
    2. In order to solve that, we're adding a clean-up phase on
    ensure which will schedule possible staled +deleted path deletion.
    Note that we don't check the current state (if there is or not a
    repo) in order to schedule the deletion. That's intentional
    in order to leverage Gitlab::GitalyClient::NamespaceService#remove
    idempotency and ensure consistency.