Gitlab 12.X-从预接收挂钩中的存储路径获取项目ID [英] Gitlab 12.X - Get project id from storage path in a pre-receive hook

问题描述

使用旧式存储，当预接收钩子触发时，很容易猜测所涉及的存储库的URL，因为路径为"group/project-name.git".

With legacy storage, when a pre-receive hook fires, it is easy to guess the URL of the repository involved as the path is "group/project-name.git".

在Gitlab中使用新的哈希存储时，如果项目ID为2，则"pwd"命令将返回诸如d4735e3a265e16eee03f59718b9b5d03019c07d8b6c51f90da3a666eec13ab35.git之类的路径.

With new hashed storage in Gitlab, the "pwd" command will return a path such as d4735e3a265e16eee03f59718b9b5d03019c07d8b6c51f90da3a666eec13ab35.git if the project id is 2.

=>如何根据哈希路径获取项目ID?

=> How can I get the project id based on the hashed path ?

我的目的是检查某个人推送的所有提交均由实际有权在该项目中编写的人员创作.如果我不知道涉及哪个项目，则无法这样做.尽管我可以启动"gitlab-rails控制台"并使用"ProjectRepository.find_by"，但在钩子上下文中使用该脚本是不切实际的.

My aim is to check that all the commits being pushed by someone are authored by people who are actually authorized to write inside that project. I cannot do so if I do not know which project is involved. Although I can launch the "gitlab-rails console" and used "ProjectRepository.find_by", it is not practical to use that script in the context of a hook.

有允许执行此操作的推送规则".但是，推送规则不是免费的，并且在Gitlab CE中不可用.

There are Push Rules that allows to do that. However, Push Rules are not free and are not available in Gitlab CE.

此外，从管理员的角度来看，重要的是能够不必基于存储库的存储路径快速找到存储库的项目ID，而不必启动"gitlab-rails控制台".

Also, from an admin point of view, it is important to be able to find quickly the project id of a repository based on its repository storage path without necessarily having to launch the "gitlab-rails console".

推荐答案

pre-receive 挂钩- GL_REPOSITORY 有一个可用的环境变量，它将具有一个值例如 project-123 .这是项目ID.

There is an environment variable available to the pre-receive hook - GL_REPOSITORY which will have a value like project-123. This is the project ID.

这篇关于Gitlab 12.X-从预接收挂钩中的存储路径获取项目ID的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！