[go: up one dir, main page]
Skip to content

'Remove blobs' feature fails on previously forked projects

Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.

Summary

Remove blobs feature might not work if the following conditions are met:

  • A fork was created for the project
  • The fork was later removed
  • Offending blobs are part of the old pool

Steps to reproduce

  • Create a project as interrnal or public
  • Add some blobs
  • Fork the project
  • Remove the fork
  • Try deleting the blobs using Remove blobs feature.

Example Project

What is the current bug behavior?

Blobs will not be removed.

What is the expected correct behavior?

Blobs should be removed if the project is no more in a fork relationship.

Relevant logs and/or screenshots

Output of checks

Results of GitLab environment info

Expand for output related to GitLab environment info 

  (For installations with omnibus-gitlab package run and paste the output of: \\\`sudo gitlab-rake gitlab:env:info\\\`)  (For installations from source run and paste the output of: \\\`sudo -u git -H bundle exec rake gitlab:env:info RAILS_ENV=production\\\`)

Results of GitLab application Check

Expand for output related to the GitLab application check 

 (For installations with omnibus-gitlab package run and paste the output of: \`sudo gitlab-rake gitlab:check SANITIZE=true\`)  (For installations from source run and paste the output of: \`sudo -u git -H bundle exec rake gitlab:check RAILS_ENV=production SANITIZE=true\`)  (we will only investigate if the tests are passing)

Workaround

To check if the files are still part of the repository, even after running remove blobs and prune objects tasks (30 minutes later) from the UI, run the following commands from within the hashed path of the repository in the server:

sudo -u git /opt/gitlab/embedded/bin/git cat-file -e <blob_id>
echo $?

If the above output returns 0, then the file exists. To get the pool repo path, run:

cat objects/info/alternates

Now, check if the project is part of the fork network:

project = Project.find_by_full_path('<namespace/project>')
project.fork_network
project.pool_repository.member_projects

If it is the only project that's part of its fork network, TAKE A BACKUP of the repository and then disconnect the pool:

project = Project.find(<project_id>)
project.leave_pool_repository

This should delete the pool and the next gc/housekeeping should cleanup the dangling files. DO NOT run this step if the pool is being used by other projects.

Edited by John Gaughan