Gitlab-shell hooks can no longer send absolute paths to gitlab-ce
The following is all to do with handling git push
.
In three places, the gitlab-shell hooks send messages to gitlab-ce where they reference a project by the absolute path to the repository on disk.
Once Gitaly is capable of running on a remote server, we can no longer assume that the mount points of Git repository data drives are the same between the Gitaly server and the server that runs gitlab-ce code. (Eventually, the gitlab-ce server will have no disk access to the repositories at all, but that will be a while.) It may be that the hook, running on the Gitaly server, 'thinks' /exports/storage01/repositories/foo/bar.git
is the absolute path to the repository, while it is /mnt/nfs/storage01/repositories/foo/bar.git
on the gitlab-ce server.
I think we should solve this problem by letting the hooks use an identifier for the project that is independent of the disk path. It could look like this:
- when pre-authorizing the request, gitlab-shell/gitlab-workhorse receive a
project_id
value in the authorization response - gitlab-shell/gitlab-workhorse set a (new) variable
GL_PROJECT_ID
when spawninggit receive-pack
- gitlab-shell hooks pass the value of
GL_PROJECT_ID
along with their messages to gitlab-ce
We should not remove the old identifier (repo_path
) from the messages because that would complicate upgrades, and some messages are delivered asynchronously so they may arrive late.
This issue is blocking https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/10150 and gitaly#144 (closed). This issue blocks us from being able to run Gitaly on a remote server, which is something we want for 9.1.