The source project of this merge request has been removed.
Fix repository archive generation when hashed storage is enabled
What does this MR do?
Uses the correct archive prefix when hashed storage is enabled
Are there points in the code the reviewer needs to double check?
My intent here was to keep the diff as small as possible, since we'd like it in 11.0. This means that I didn't make a large number of very sensible refactorings; I intend to open issues for them:
- Remove
Gitlab::Git::Repository#name
altogether: https://gitlab.com/gitlab-org/gitlab-ce/issues/47341 - Move
archive_metadata
and friends out ofRepository
altogether - Pass
Project#full_path
toGitlab::Git::Repository
on initialization (it's passed in in a couple of places) - Audit other users of
Gitlab::Git::Repository#relative_path or #name
for problems: https://gitlab.com/gitlab-org/gitlab-ce/issues/47342 - ...
Why was this MR needed?
Without this, the "download .tar.gz" links for a project with hashed storage do not work as expected. The wrong filename is used for the archive, and the top-level member within the archive has the wrong name. This will break using these archives as build/deployment artifacts, which is very common (omnibus-gitlab, a large number of archlinux recipes, etc), which blocks enabling hashed storage as a consequence.
Screenshots (if relevant)
Does this MR meet the acceptance criteria?
-
Changelog entry added, if necessary -
Tests added for this feature/bug - Conform by the code review guidelines
-
Has been reviewed by a Backend maintainer
-
-
Conform by the merge request performance guides -
Conform by the style guides -
If you have multiple commits, please combine them into a few logically organized commits by squashing them -
Internationalization required/considered -
End-to-end tests pass ( package-and-qa
manual pipeline job)
What are the relevant issue numbers?
Closes #45702 (closed)
Edited by Nick Thomas