Fix backup restore
What does this MR do?
This MR fixes the backup restore task.
Are there points in the code the reviewer needs to double check?
Whether the mode 0277 makes sense. (Group SUID + group/user read/write permissions)
Why was this MR needed?
86359ec8 broke this, and it was not caught by any specs. Users would see:
Restoring repositories ...
rake aborted!
NameError: undefined local variable or method `repos_path' for #<Backup::Repository:0x00000007cea1d8>
/opt/gitlab/embedded/service/gitlab-rails/lib/backup/repository.rb:59:in `restore'
/opt/gitlab/embedded/service/gitlab-rails/lib/tasks/gitlab/backup.rake:79:in `block (4 levels) in <top (required)>'
/opt/gitlab/embedded/service/gitlab-rails/lib/tasks/gitlab/backup.rake:54:in `block (3 levels) in <top (required)>'
Tasks: TOP => gitlab:backup:repo:restore
(See full trace by running task with --trace)
What are the relevant issue numbers?
Does this MR meet the acceptance criteria?
-
CHANGELOG entry added - Tests
-
Added for this feature/bug -
All builds are passing
-
-
Conform by the style guides -
Branch has no merge conflicts with master
(if you do - rebase it please) -
Squashed related commits together
Merge request reports
Activity
mentioned in issue #20188 (closed)
mentioned in issue #19582 (closed)
Added 1 commit:
- c07f8f2e - Checkout gitlab-shell
Added 1 commit:
- 8469f9e0 - Fix backup restore
Marked the task Conform by the style guides as completed
Marked the task Squashed related commits together as completed
Marked the task CHANGELOG entry added as completed
Milestone changed to %8.10
Added 1 commit:
- da12adc3 - Set permissions of backup dir to g+s
Added 17 commits:
-
da12adc3...83180110 - 15 commits from branch
master
- 4fb3b9bf - Fix backup restore
- a1f07a86 - Set permissions of backup dir to g+s
-
da12adc3...83180110 - 15 commits from branch
Reassigned to @rymai
Added 16 commits:
-
a1f07a86...89872574 - 15 commits from branch
master
- c6ff77d4 - Fix backup restore
-
a1f07a86...89872574 - 15 commits from branch
mentioned in commit c4ba2b15
mentioned in issue #20242 (closed)
Please register or sign in to reply