GitLab пост-приемный крюк не стреляет
Извиняюсь, если это не правильный обмен стека.
У меня установлена 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>
Я исчерпал идеи отладки на этом. У кого-нибудь есть предложения?
2 ответа
ОК, понял это. Возможно, эта ситуация применима и к другим людям, поэтому я задокументировал это.
В нашей инфраструктуре есть все внешние соединения SSH, которые приземляются на определенную машину1. Это не машина, на которой работает gitlab. Это не было очевидно, потому что gitolite+gitlab работает, несмотря на это. Наши домашние каталоги - это монтирования 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 перенаправить в скрипт хука. Хотя я и удалил его во время отладки, я, должно быть, восстановил его, прежде чем пытался вызвать ловушку через git push, который в противном случае повторил бы ошибку.
Мое предположение о моей слегка нестандартной установке gitlab оказалось неверным. Эта проблема произошла бы независимо; это связано с особенностями сети. В любом случае, я надеюсь, что это кому-нибудь пригодится.
- В случае с git мы используем внешние URL-адреса даже внутри локальной сети, чтобы URL-адреса проекта были согласованы независимо от сетевой среды.
У меня была та же проблема, но причина была в другом.
мой 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
Это решило мою проблему с крюком пост-получения, не стреляющим.
Я надеюсь, что это будет полезно и для кого-то еще.