Gancho pós-recebimento do GitLab não disparando

Question

Desculpas se este não for o stackexchange correto.

Eu tenho uma instalação do GitLab. Ele foi instalado por cima de uma instalação de gitolite que tinha apenas alguns dias, e eu assumo que essa configuração não padrão está na raiz do meu problema, mas não consigo defini-lo.

O problema é simples: ganchos pós-recebimento não são disparados. Isso impede que a 'atividade do projeto' apareça no GitLab. O problema parece:

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

Gancho existente

O hook / symlink de pós-recepção existe e é executável:

-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

É executável pelo GitLab

O usuário do gitlab pode executar o script (eu removi o /dev/null redirect e o feed em branco para obter um 'OK' como saída):

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

OK

O GitLab pode encontrá-lo

O GitLab está procurando por ganchos no local correto:

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

e

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

O GitLab é executado como usuário correto

O software GitLab está sendo executado pelo usuário do 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
# ...

Ambiente

A linha env -i no gancho é comumente citada como um problema. Eu acho que isso ocorreria após este problema, mas para completar, redis-cli foi encontrado OK:

$ env -i redis-cli
redis>

Eu fiquei sem ideias de depuração neste. Alguém tem alguma sugestão?

    

Answer 1

OK, percebi isso. É remotamente possível que esta situação se aplique a outras pessoas, por isso eu documentei isso.

Nossa infra-estrutura tem todas as conexões SSH externas em uma determinada máquina ¹ . Esta não é a máquina que executa o gitlab. Isso não era óbvio porque o gitolite + gitlab funciona apesar disso. Nossos homedirs são montagens NFS e tanto a máquina SSH quanto a máquina gitlab vêem os arquivos gitolite como 'locais'. O único problema com esse gitolite 'distribuído' + gitlab é que o post-receive hook tenta chamar redis-cli , um binário que não existe na máquina que está executando o gancho.

Para resolver o problema, eu instalei o pacote redis-server na máquina aceitando conexões SSH (infelizmente o binário redis-cli não parece estar disponível separadamente). Em seguida, modifiquei a linha de redis em /home/git/.gitolite/hooks/common/post-receive para o seguinte:

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

A opção -h hostname é a única adição. Isso faz com que o comando redis rpush seja enviado para os redis na máquina correta.

O erro binário ausente não surgiu devido ao redirecionamento > /dev/null 2>&1 no script de gancho. Embora eu tenha removido durante a depuração, devo tê-lo restaurado antes de tentar acionar o gancho por meio de um git push , que de outra forma teria ecoado no erro.

Minha suposição sobre a instalação do Gitlab, que não é padrão, acabou sendo incorreta. Esse problema teria ocorrido independentemente; é devido a uma peculiaridade de rede. De qualquer forma, espero que isso seja útil para alguém.

1. No caso do git, usamos URLs externos, mesmo dentro da rede local, para que as URLs do projeto sejam consistentes, independentemente do ambiente de rede.

Answer 2

Eu tive o mesmo problema, mas o motivo foi diferente.

Minha instalação redis estava em /usr/local/bin . O usuário do Git o tinha em PATH , mas sem efeito.

Eu tive que deixar claro no script para iniciar os redis de /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

Ele resolveu meu problema com o gancho pós-recebimento não sendo acionado.

Espero que isso seja útil para outra pessoa também.