Relative path for gitlab_repository_downloads_path breaks the archive cleanup

Summary

Tested on 13.7.1-ee

Setting a relative path in gitlab_rails['gitlab_repository_downloads_path'] prevents the app/services/repository_archive_clean_up_service.rb worker from cleaning up archives. The worker is expecting an absolute path.

Over time, disk space continues to grow since the archives aren't being deleted.

I've labelled this a ~bug because downloading the project as a zip seems to work with a relative path specified.

Steps to reproduce

  1. In the /etc/gitlab/gitlab.rb file, set this and run sudo gitlab-ctl reconfigure:

    gitlab_rails['gitlab_repository_downloads_path'] = 'tmp/repositories'

    Since we used a relative path, the archives will be downloaded to /var/opt/gitlab/gitlab-workhorse/tmp/repositories.

  2. Download the project as a zip. Observe that the archive generated now exists in the /var/opt/gitlab/gitlab-workhorse/tmp/repositories folder.

  3. In sudo gitlab-rails c, let's run the following commands:

    # Get the current gitlab_repository_downloads_path (will return a relative path instead of absolute path)
Gitlab.config.gitlab.repository_downloads_path

# Run the RepositoryArchiveCleanUpService manually
RepositoryArchiveCleanUpService.new(0).execute

  4. Observe in the /var/opt/gitlab/gitlab-workhorse/tmp/repositories folder that the archive generated in step 2 wasn't deleted.

What is the current bug behavior?

Archived projects aren't automatically cleaned up if a relative path for gitlab_rails['gitlab_repository_downloads_path'] is configured.

What is the expected correct behavior?

Archived projects should be automatically cleaned up if a relative path for gitlab_rails['gitlab_repository_downloads_path'] is configured.

If GitLab is able to generate and download archives with a relative path, then it should be able to use a relative path for the cleanup worker as well.

Alternatively we should update config/gitlab.yml.example#L157-160 and gitlab-config-template/gitlab.rb.template#L143-147 that this should be an absolute path as the current example shows a relative path.

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)

Possible fixes

Workaround

Ensure that an absolute path is used in the gitlab_rails['gitlab_repository_downloads_path'] setting.

Edited by Anton Smith