Приносим извинения, если это не тот стек.
У меня установлен GitLab. Он был установлен поверх установки gitolite, которая была всего несколько дней назад, и я предполагаю, что эта нестандартная установка является корнем моей проблемы, но я не могу ее определить.
Проблема проста: перехватчики после получения не запускаются. Это предотвращает появление «активности проекта» в 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 перенаправить и передать пустой ввод, чтобы получить на выходе «ОК»):
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. Это было неочевидно, потому что, несмотря на это, гитолит + gitlab работает. Наши домашние устройства - это монтирования NFS, и как машина SSH, так и машина gitlab видят файлы 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 перенаправление в скрипте перехвата. Хотя я удалил его во время отладки, я, должно быть, восстановил его до того, как попытался вызвать перехватчик через git push, что в противном случае привело бы к ошибке.
Мое предположение о моей немного нестандартной установке gitlab оказалось неверным. Эта проблема возникла бы в любом случае; это из-за сетевой причуды. Во всяком случае, я надеюсь, что это будет кому-то полезно.
У меня была такая же проблема, но причина была в другой.
Мой redis установка была на /usr/local/bin. У пользователя Git это было в PATH, но без эффекта.
Я должен был сделать это очевидным в сценарии, чтобы запустить Redis из /usr/local/bin/redis-cli:
env -i /usr/local/bin/redis-cli rpush "resque:queue:post_receive" "{\"class\":\"PostReceive\",\"args\":[\"$reponame\",\"$oldrev\",\"$newrev\",\"$ref\",\"$GL_USER\"]}" > /dev/null 2>&1
Это решило мою проблему с не срабатывающим крючком после получения.
Я надеюсь, что это будет полезно и для кого-то другого.