如何在从 13.1 开始的服务器端 Gitlab 全局挂钩中获取组和存储库名称

Question

我的组织使用 Gitlab CE 和服务器端 git 挂钩。 具体来说，我们使用全局预接收挂钩来验证提交消息（放置在/opt/gitlab/embedded/service/gitlab-shell/hooks/pre-receive.d中的那个）。 不同的 Gitlab 组的验证规则不同，因此脚本会解析存储库的完整路径，并根据组应用不同的规则。

我们过去使用PWD环境变量来获取存储库的完整路径，包括组。 但看起来从 Gitlab 13.1开始，这个变量不再可用。 此外，由于在 @hashed 文件夹中创建了新的存储库，因此无论如何都需要调整这种方法。

我们尝试在 pre-recieve 挂钩中使用git config --get gitlab.fullpath ，到目前为止它适用于除 wiki 存储库之外的所有存储库（如<project_name>.wiki.git ） 此外，这不是一个记录在案的方法，因此将来可能会再次中断。 是否有任何官方方法可以在预接收挂钩中获取组名？

UPD：看起来有一个使用 gitlab-rails 的解决方法，但它远非最佳：

1. GIT_OBJECT_DIRECTORY环境变量包含类似/var/opt/gitlab/git-data/repositories/@hashed/dd/8e/dd8e8c8c9dae8978f122d7bcf3d0d49f6a0e86b9fc35528f55e78f7408927bb1.git/objects/incoming-16WBe9目录的路径
2. Extract the repo hash from the path above and use the following command to lookup the full path: gitlab-rails runner "puts ProjectRepository.find_by(disk_path: '@hashed/dd/8e/dd8e8c8c9dae8978f122d7bcf3d0d49f6a0e86b9fc35528f55e78f7408927bb1').project.full_path"

但是这种方法的问题是GIT_OBJECT_DIRECTORY将来可能会发生变化，并且gitlab_rails命令在我们的安装上执行大约需要 30 秒，这是不可接受的长

UPD2：项目ID有GL_REPOSITORY环境变量，可用于查找完整路径： https://stackoverflow.com/a/57399790/13881221

UPD3 2020-07-07：包含从 Gitlab 13.1.3开始的GL_PROJECT_PATH环境变量，可解决问题https://gitlab.com/gitlab-org/gitaly/-/merge_requests/2313

Answer 1

实际上 GL_PROJECT_PATH 有这种格式：
group/subgroup/repo_name
您可以在 git 服务器上自定义更新挂钩，并从那里使用组或子组。
例如，您可以使用正则表达式来获取组名，如下所示：
cut -d'/' -f1 <<< $GL_PROJECT_PATH
有关 git 挂钩的更多信息： https://git-scm.com/book/en/v2/Customizing-Git-Git-Hooks