Audit Gitlab::Git::Repository#relative_path usage with Hashed Storage enabled
Context
GitLab 10.0 introduced the Hashed Storage, decoupling a project's path on disk from the URL route.
The previous Project#path_with_namespace
method is now deprecated and the new ones are:
-
Project#disk_path
- path segment for the in disk location (this is based on the Hash from the project ID, when using the Hashed Storage) -
Project#full_path
- path segment for the URL route (this is based on the project slug and group/namespace slugs)
They both behave differently if the project is already using the Hashed Storage or Legacy Storage.
Problem
With the Hashed Storage and this changes, projects can be renamed without performing a mv
on disk.
There are still leftovers in some parts of the codebase that are not fully aware of the interchangeable storage layouts:
Gitlab::Git::Repository
only has access to the disk_path
version (which it calls relative_path
), but needs to use the full_path
version in at least two places - writing the full_path
to the configuration, and generating the archive_metadata
used when packaging a repository up into a tarball.
It's possible there are other uses within Gitlab::Git::Repository
, or code that uses its #relative_path
or #name
accessors, that should actually use the full_path
version. We should audit to ensure that no cases like that exist.
What needs to be done
We need to audit the mentioned classes and see if they are still using only the relative_path instead of the disk_path
and full_path
to get the expected behavior.