GitLab 接收後掛鉤未觸發

如果這不是正確的堆棧交換，請道歉。

我有一個 GitLab 安裝。它安裝在僅幾天前的 gitolite 安裝之上，我認為這種非標准設置是我問題的根源，但我無法確定它。

問題很簡單：沒有觸發 post-receive 鉤子。這可以防止“項目活動”出現在 GitLab 中。問題看起來像：

$ git push
#...
error: cannot run hooks/post-receive: No such file or directory

鉤子存在

接收後掛鉤/符號連結存在並且是可執行的：

-rwxr-xr-x 1 git git 470 Oct  3  2012 .gitolite/hooks/common/post-receive
lrwxrwxrwx 1 git git  45 Oct  3  2012 repositories/project.git/hooks/post-receive -> /home/git/.gitolite/hooks/common/post-receive

它可以由 GitLab 執行

gitlab 使用者可以執行腳本（我已刪除/dev/null重定向並輸入空白輸入以獲得“OK”作為輸出）：

sudo su - gitlab -c /home/git/.gitolite/hooks/common/post-receive

OK

GitLab 可以找到它

GitLab 正在尋找正確位置的鉤子：

$ grep hooks /srv/gitlab/gitlab/config/gitlab.yml
 hooks_path: /home/git/.gitolite/hooks/

和

$ bundle exec rake gitlab:app:status RAILS_ENV=production
# ...
/home/git/.gitolite/hooks/common/post-receive exists? ............YES

GitLab 以正確的使用者身份執行

GitLab 軟體由 gitlab 使用者執行：

$ ps U gitlab
 PID TTY      STAT   TIME COMMAND
3650 ?        Sl     0:59 unicorn_rails master -c /srv/gitlab/gitlab/config/unicorn.rb -E production -D
3671 ?        Sl     0:43 unicorn_rails worker[0] -c /srv/gitlab/gitlab/config/unicorn.rb -E production -D
3674 ?        Sl     0:42 unicorn_rails worker[1] -c /srv/gitlab/gitlab/config/unicorn.rb -E production -D
# ...

環境

鉤子中的env -i線通常被認為是一個問題。我認為在此問題之後會發生這種情況，但為了完整起見，redis-cli發現可以：

$ env -i redis-cli
redis>

我已經沒有關於這個的調試想法了。有人有什麼建議嗎？

好的，想通了這一點。這種情況很可能適用於其他人，所以我已經記錄了它。

我們的基礎設施的所有外部 SSH 連接都登陸特定的機器1。這不是執行 gitlab 的機器。這並不明顯，因為儘管如此 gitolite+gitlab 仍然有效。我們的 homedirs 是 NFS 掛載，SSH 機器和 gitlab 機器都將 gitolite 文件視為“本地”文件。這個“分佈式”gitolite+gitlab 的一個問題是post-receive鉤子試圖呼叫redis-cli，一個在執行鉤子的機器上不存在的二進製文件。

為了解決這個問題，我redis-server在接受 SSH 連接的機器上安裝了這個包（不幸的是，redis-cli二進製文件似乎沒有單獨提供）。然後我將redis行修改為/home/git/.gitolite/hooks/common/post-receive以下內容：

redis-cli -h hostname rpush "resque:queue:post_receive" "{\"class\":\"PostReceive\",\"args\":[\"$reponame\",\"$oldrev\",\"$newrev\",\"$ref\",\"$GL_USER\"]}" > /dev/null 2>&1

-h hostname開關是唯一的補充。這會導致將 redis rpush 命令發送到正確機器上的 redis。

> /dev/null 2>&1由於掛鉤腳本中的重定向，失去的二進制錯誤沒有出現。儘管我在調試期間確實刪除了它，但我必須在嘗試通過 a 觸發鉤子之前恢復它git push，否則會回顯錯誤。

我對我稍微不標準的 gitlab 安裝的假設結果證明是不正確的。無論如何都會發生此問題；這是由於網路怪癖。無論如何，我希望這對某人有用。

1. 在 git 的情況下，我們甚至在本地網路中也使用外部 URL，因此無論網路環境如何，項目 URL 都是一致的。

引用自：https://serverfault.com/questions/433947