GitLab hook post-ricezione non sparare

Ci scusiamo se questa non è la giusta stackexchange.

Ho un'installazione GitLab. È stato installato sulla parte superiore di un'installazione di gitolite che aveva solo pochi giorni, e suppongo che questa configuration non standard sia alla base del mio problema, ma non posso farcela.

Il problema è semplice: i ganci post-ricezione non vengono licenziati. Ciò impedisce che l'attività di progetto venga visualizzata in GitLab. Il problema sembra:

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

Gancio esiste

Il hook / sillabordo post-riceve esiste ed è eseguibile:

 -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 

È eseguibile da GitLab

L'utente gitlab può eseguire lo script (ho rimosso il reindirizzamento /dev/null e inserito in input vuoto per get un 'OK' come output):

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

GitLab può trovarlo

GitLab cerca ganci nella posizione corretta:

 $ 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 

GitLab esegue come utente corretto

Il software GitLab viene eseguito dall'utente 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

La linea env -i nel hook è comunemente citata come un problema. Penso che si verificherebbe dopo questo problema, ma per completezza, il redis-cli è trovato OK:

 $ env -i redis-cli redis> 

Ho esaurito le idee di debug su questo. Qualcuno ha qualche suggerimento?

  • Gitlab e Nginx non caricano gitlab
  • Triggering Jenkins build per la richiesta di unione da GitLab web hook
  • È sicuro esporre pubblicamente strumenti dev / team senza VPN?
  • I sottogruppi possono essere creati in Gitlab?
  • GitLab Distribuzione automatica
  • Gitlab non funziona con i tasti SSH
  • Come redirect le richieste di http a https (nginx)
  • Il hook personalizzato post-commit di GitLab CE non funziona
  • 2 Solutions collect form web for “GitLab hook post-ricezione non sparare”

    Okay, questa figurò fuori. È ansible da remoto che questa situazione si applicherà ad altre persone, quindi l'ho documentata.

    La nostra infrastruttura dispone di tutte le connessioni esterne SSH atterraggio su una particolare macchina 1 . Questa non è la macchina che esegue gitlab. Questo non era ovvio perché gitolite + gitlab funziona nonostante questo. I nostri homedirs sono i supporti NFS e sia la macchina SSH che la macchina gitlab vedono i file di gitolite come "locali". L'unico problema con questo 'distribuito' gitolite + gitlab è che il hook post-receive cerca di call redis-cli , un binario che non esiste sulla macchina che gestisce l'hook.

    Per risolvere il problema, ho installato il pacchetto redis-server sulla macchina che accetta le connessioni SSH (purtroppo il binario redis-cli non sembra essere disponibile separatamente). Ho quindi modificato la linea /home/git/.gitolite/hooks/common/post-receive in /home/git/.gitolite/hooks/common/post-receive a quanto segue:

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

    L'interruttore -h hostname è l'unica aggiunta. In questo modo il command redis rpush viene inviato a redis sulla macchina corretta.

    L'errore binario mancante non è stato superato a causa del > /dev/null 2>&1 reindirizzamento nello script hook. Anche se l'ho rimosso durante il debug, ho dovuto ripristinarlo prima di tentare di innescare il hook tramite una git push , che altrimenti avrebbe echeggiato l'errore.

    La mia ipotesi sulla mia installazione leggermente non standard di gitlab si è rivelata inesatta. Questo problema sarebbe accaduto indipendentemente; è dovuto a un quirk di networking. Comunque, spero che questo sarà utile per qualcuno.

    1. Nel caso di git, utilizziamo gli URL esterni anche all'interno della networking locale in modo che gli URL del progetto siano coerenti indipendentemente dall'ambiente di networking.

    Ho avuto lo stesso problema ma la ragione era diversa.

    La mia installazione di redis era in /usr/local/bin . L'utente Git lo aveva nel suo PATH , ma senza alcun effetto.

    Ho dovuto rendere ovvio nello script per iniziare a redis da /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 

    Ha risolto il mio problema con il hook post-ricezione che non spara.

    Spero che questo sia utile anche per qualcun altro.

    Suggerimenti per Linux e Windows Server, quali Ubuntu, Centos, Apache, Nginx, Debian e argomenti di rete.