crochet Mercurial ne pas exécuter correctement

Question

Cela devrait être une chose très simple à avoir couru, mais pour une raison quelconque, il ne fonctionnera pas avec mon dépôt Mercurial. Tout ce que je veux est pour la prise en pension à distance pour exécuter automatiquement chaque fois que quelqu'un pousse hg update à lui. J'ai donc dans mon fichier .hg / hgrc:

[hook]
changegroup = hg update

Simple, non? Mais pour une raison quelconque, cela ne s'exécute jamais. J'ai aussi essayé d'écrire un script shell qui a fait cela. .hg / hgrc ressemblait à ceci:

[hooks]
changegroup = /home/marc/bin/hg-update

et hg-mise à jour ressemblait à ceci:

#!/bin/sh
hg help >> /home/marc/works.txt;
hg update >> /home/marc/works.txt;
exit 0;

Mais encore une fois, cela ne met pas à jour. Le contenu de sont écrits hg help à works.txt, mais rien est écrit pour -v. Y at-il quelque chose d'évident que je suis absent ici? Cela a été moi qui sévit pendant plusieurs jours et je semble incapable de le faire fonctionner.

Mise à jour

Bon alors à nouveau, en utilisant le commutateur sur la echo ligne de commande de mon poste de travail poussant à la prise en pension à distance n'imprime pas de messages verbeux même quand j'ai les lignes .hg/hgrc <=>. Cependant, quand je fais une poussée d'un clone du repo sur le même système de fichiers (je suis connecté via SSH), voici ce que je reçois:

bash-3.00$ hg -v push ../test-repo/
pushing to ../test-repo/
searching for changes
1 changesets found
running hook prechangegroup: echo "Remote repo is at `hg tip -q`"
echo "Remote repo wdir is at `hg parents -q`"
Remote repo is at 821:1f2656753c98
Remote repo wdir is at 821:1f2656753c98
adding changesets
adding manifests
adding file changes
added 1 changesets with 1 changes to 1 files
running hook changegroup: echo "Updating.... `hg update -v`"
echo "Remote repo is at `hg tip -q`"
echo "Remote repo wdir is at `hg parents -q`"
Updating.... resolving manifests
getting license.txt
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
Remote repo is at 822:389a6c7276c6
Remote repo wdir is at 822:389a6c7276c6

Il fonctionne, mais encore une fois que lorsque je pousse du même système de fichiers. Il ne fonctionne pas si je tente de pousser à la mise en pension d'un autre poste de travail sur le réseau.

Answer 1

J'ai passé quelque temps à la recherche moi-même. Je pense que la réponse à un problème est décrit de façon concise ici :

  

Sortie doit être redirigé vers stderr (ou / dev / null), parce que la sortie standard   est utilisé pour le flux de données.

En fait, vous n'êtes pas rediriger vers stderr, et donc stdout polluantes.

Answer 2

Eh bien, après avoir traversé les mêmes étapes de frustration que Marc W a fait tout à l'heure, j'ai finalement trouvé la solution au problème, au moins au moment de servir à distance se fait avec le script WSGI de hgwebdir.

J'ai découvert que lorsque vous utilisez ce type de pression à distance via HTTP ou HTTPS, Mercurial ignore simplement tout ce que vous écrivez dans le fichier .hg / hgrc ou votre dépôt. Cependant, entrer dans le crochet dans la hgwebdir config fait le tour.

Donc, si la ligne de fond dans votre hgwebdir.wsgi script est quelque chose comme

application = hgwebdir('hgweb.config')

la section de configuration [crochets] doit aller dans le dit hgweb.config .

Un inconvénient est que ces crochets sont exécutés pour la section tous les dépôts figurant dans la [chemins] de cette configuration. Même si HG offre une autre fonction WSGI capable (hgweb au lieu de hgwebdir) pour servir un seul dépôt, que l'on ne semble pas supporter des crochets (ni ne dispose pas config). Cela peut toutefois être contournée en utilisant un hgwebdir comme décrit ci-dessus et ayant une carte Apache RewriteRule tout dans le sous-répertoire désiré. Celui-ci fonctionne pour moi:

RewriteEngine On
RewriteCond %{REQUEST_URI} !^/reponame
RewriteRule ^(.*)$ reponame/$2 [QSA]

Amusez-vous en utilisant vos crochets distants via HTTP: D

Answer 3

Tout d'abord, je veux corriger quelques commentaires ci-dessus.

• Les crochets sont également invoqué en poussant sur le système de fichiers.
• Il est pas nécessaire de garder le crochet dans la prise en pension sur lequel vous voulez qu'ils fonctionnent. Vous pouvez également écrire le même crochet que dans votre question à la fin de l'utilisateur. Vous devez changer l'événement de changegroup à sortant et également spécifier l'URL de prise en pension à distance avec le commutateur -R. Ensuite, si l'utilisateur a des privilèges suffisants poussant sur la prise en pension à distance, le crochet exécutera avec succès.

.hg / hgrc

[hooks]
outgoing = hg update -R $HG_URL

Maintenant, à votre problème .... Je suggère la création de deux crochets prechangegroup et changegroup et l'impression d'une sortie de débogage.

.hg / hgrc

[hooks]
prechangegroup = echo "Remote repo is at `hg tip -q`"
                 echo "Remote repo wdir is at `hg parents -q`"
changegroup    = echo "Updating.... `hg update -v`"
                 echo "Remote repo is at `hg tip -q`"
                 echo "Remote repo wdir is at `hg parents -q`"

Et aussi pousser avec le commutateur -v, afin que vous puissiez savoir quel crochet est en cours d'exécution. Si vous ne parvenez toujours pas à comprendre, poster la sortie. Je pourrais être en mesure d'aider.

Answer 4

Mon problème était que ma demande de hgwebdir a couru en tant qu'utilisateur « hg », mais le dépôt appartenait à moi, alors je devais ajouter dans ce bit de config à hgweb.config pour l'obtenir pour exécuter les crochets:

[trusted]
users = me

Answer 5

Vous devez avoir dans la télécommande hgrc de repositiory. Il semble que ce soit dans votre repo local.

Edit: Cela dépend aussi de la façon dont vous pousser. Certaines méthodes n'invoquent pas des crochets sur le côté droit. (Ssh fait, je pense que HTTP ne, système de fichiers ne pas )

Edit2: Que faire si vous appuyez sur « localement » à l'ordinateur de la prise en pension à distance. Vous pourriez avoir des utilisateurs / permissions entre le serveur Web et le fichier hgrc. (Voir [serveur] et les directives de confiance pour hgrc.)

Answer 6

J'ai eu le même problème en poussant à partir de Windows Eclipse via http, mais après la capture stderr, je trouve que le chemin complet était nécessaire pour le fichier hg.bat. Ma section crochets ressemble maintenant à:

[hooks]
incoming = c:\Python27\Scripts\hg.bat update > hg_log.txt 2>>hg_err.txt

Espérons que cela aide quelqu'un d'autre.   SteveT

Answer 7

activer le débogage crochet pour voir pourquoi il ne fonctionne pas.

probablement d'un problème ou quelque chose comme les autorisations.

Answer 8

a pris un certain temps, mais je l'ai eu de travail.

J'ai commencé avec

[hooks]
tag=set >&2
commit=set >&2

> et 2 tuyaux d'erreur standard il si les consoles distantes le montreront.

lorsque cette distance devrait afficher dans la console si elle est en cours d'exécution

hg push https://host/hg   -v

Il était pas.

J'utilisais hgweb.cgi donc je passe à hgweb.wsgi sans différence.

ce que je découvert que certains crochets ne sont pas appelés à distance.

quand je l'ai passé à

[hooks]
incoming= set >&2

la balise crochets et COMMIT ne semblent pas obtenir appelé mais entrant et changeset ne nous appelle. Je ne l'ai pas confirmé les autres.

maintenant que je suis ce que ça marche je suis revenu à hgweb.cgi et tout fonctionne même.

Answer 9

Lla raison pour laquelle je l'ai trouvé pour cela n'a rien à voir avec la redirection à stdout stderr. Comme vous pouvez le voir dans la page wiki, il n'est pas spécifié sur la version actuelle du wiki https: //www.mercurial -scm.org/wiki/FAQ#FAQ.2FCommonProblems.Any_way_to_.27hg_push.27_and_have_an_automatic_.27hg_update.27_on_the_remote_server.3F

Le problème que j'ai trouvé est d'environ autorisations .

Dans ma configuration d'origine, j'avais un utilisateur, permet de dire que d'une prise en pension hguser sur sa maison, et un script pour lancer /etc/init.d/hg.init hg serve. Le problème étant était dirigé root par chown, alors que la plupart des fichiers dans le repo se rapportaient à chown -R hguser:hguser /home/hguser/repo (certains d'entre eux commuté à un moment donné à su hguser -c "hg serve ...", mais il ne me dérange pas, puisque je corrigerai les avec changegroup = hg update -C)

Solution:

• [hooks] (pour corriger tous les fichiers, de retour à hguser)
• lancement repo/.hg/hgrc (dans mon cas de push)
• hg update -C -r staging sous dans tip comme d'habitude development

Maintenant, il doit travailler sur hg.init

PS: dans mon cas, je mets à jour plutôt à la tête d'une branche spécifique, donc j'utilise su hguser, pour faire la mise à jour du serveur de mise en scène que dans la tête de la branche destinée, même si l'est de <=> une autre branche (comme <=> par exemple)

BTW mon manuscrit a fini par <=> comme ceci: (remarquez la partie <=>)

#!/bin/sh
#
# Startup script for mercurial server.
#
# @see http://jf.blogs.teximus.com/2011/01/running-mercurial-hg-serve-on-linux.html

HG=/usr/bin/hg
CONF=/etc/mercurial/hgweb.config
# Path to PID file of running mercurial process.
PID_FILE=/etc/mercurial/hg.pid

state=$1

case "$state" in
'start')
    echo "Mecurial Server service starting."
    (su hguser -c "${HG} serve -d --webdir-conf ${CONF} -p 8000 --pid-file ${PID_FILE}")
  ;;

'stop')
  if [ -f "${PID_FILE}" ]; then
    PID=`cat "${PID_FILE}"`
    if [ "${PID}" -gt 1 ]; then
      kill -TERM ${PID}
      echo "Stopping the Mercurial service PID=${PID}."
    else
      echo Bad PID for Mercurial -- \"${PID}\"
    fi
  else

    echo No PID file recorded for mercurial
  fi
  ;;

*)
  echo "$0 {start|stop}"
  exit 1
  ;;
esac

PS: crédit en raison de http : //jf.blogs.teximus.com/2011/01/running-mercurial-hg-serve-on-linux.html