2010-04-13 12 views
24

Ho un gancio post-aggiornamento sul mio server, in modo tale che quando hoQuale utente esegue il hook git?

git push 

lo fa un tirare la directory web dal vivo. Tuttavia, mentre il push riesce sempre, l'hook post-update a volte fallisce.

Il gancio è piuttosto semplice:

#!/bin/sh 
# 
# An example hook script to prepare a packed repository for use over 
# dumb transports. 
# 
# To enable this hook, rename this file to "post-update". 
cd /var/www 
env -i git pull 

sto spingendo gli aggiornamenti da una varietà di luoghi, ma a volte devo effettuare il login come root sul server e manuall fare un

env -i git pull 

Devo farlo solo il 20% delle volte però. Qualche idea sul perché fallirebbe a caso? Inoltre, come posso ottenere di registrare i messaggi di errore, dal momento che potrebbe essere in esecuzione come qualcuno che non può scrivere sul file system?

+0

Stai spingendo allo stesso modo da tutti questi posti? Cioè, l'URL remoto è lo stesso per tutti loro? (in particolare, la parte utente @ hostname) – Cascabel

+0

Inoltre, quando dici che fallisce, vuoi dire che fallisce con un errore di autorizzazione negato che indica che è in esecuzione come utente con privilegi insufficienti? O sta fallendo per qualche motivo completamente non correlato, niente a che fare con l'uid che lo esegue? – Cascabel

+0

In realtà sto spingendo da punti diversi: a volte è user1 @ hostname, othertimes, user2 @ hostname, ecc (tutti hanno però questo problema). Fallisce senza un messaggio di errore che posso vedere, e non sono sicuro di come ottenerne uno. Nel mio post-aggiornamento, ho aggiunto, echo $ USER> /log.txt, ma non vi è scritto nulla (né il file è stato creato). Questo mi fa pensare che l'utente che spinge, non ha permessi. Ma se non riesco nemmeno a scrivere un messaggio di errore, come faccio a saperlo? – ash

risposta

18

I ganci vengono eseguiti mentre l'utente esegue la pressione. Se si dispone di una sorta di impostazione preconfigurata, potrebbe essere un utente come git o gitosis o potrebbe essere tu. Guarda come hai configurato il telecomando. (git remote show <remote-name> o semplicemente esaminare .git/config se non lo sai) Presumibilmente stai premendo tramite SSH, e c'è un nome utente @ hostname nell'URL.

P.S. È abbastanza veloce dimostrarlo: basta clonare un repository locale, inserire un hook di post-aggiornamento con uno echo $USER o qualcosa di simile e provare a spingere te stesso o un altro utente (direttamente o tramite ssh).

2

ho deciso di provare questo sul mio server gitlab 6 con la creazione di un pre-ricezione gancio e riecheggiando le informazioni dell'utente

$ cat /home/git/repositories/foo/foo.git/hooks/pre-recieve 
#!/bin/bash 
set -x 
echo -e "The user the hook is run as is $USER" 
echo -e "Just to doublecheck, the user is $(whoami)" 
exit 1 

Sembra che viene eseguito come utente git

$ git push 
Counting objects: 3, done. 
Delta compression using up to 8 threads. 
Compressing objects: 100% (2/2), done. 
Writing objects: 100% (3/3), 269 bytes | 0 bytes/s, done. 
Total 3 (delta 1), reused 0 (delta 0) 
remote: + echo -e 'The user the hook is run as is' 
remote: The user the hook is run as is 
remote: ++ whoami 
remote: + echo -e 'Just to doublecheck, the user is git' 
remote: Just to doublecheck, the user is git 
remote: + exit 1 
+0

La ragione è che tutti questi server configurano un utente unix per accettare le connessioni ssh in entrata tramite il file '~ git/.ssh/authorized_keys'. Quel file delega tali connessioni a uno script che quindi gestisce i dati in arrivo. Per tali server si può ricavare il nome della persona che fa la spinta, ad es. assumendo che si tratti della stessa persona che ha eseguito il commit più recente. Tuttavia questo potrebbe non essere vero affatto. Dipende dal modello di lavoro degli utenti. Meglio controllare o segnalare l'autore/committer sui singoli commit. – cfi