Ртутный крюк не выполняется должным образом - PullRequest
Новая
       15

Ртутный крюк не выполняется должным образом

7 голосов
/ 11 мая 2009

Это должно быть очень просто запустить, но по какой-то причине он не будет работать с моим репозиторием Mercurial. Все, что я хочу, это чтобы удаленный репозиторий автоматически запускал hg update всякий раз, когда кто-то подталкивал к нему. Итак, у меня есть это в моем файле .hg / hgrc: 

[hook]
changegroup = hg update

Просто, верно? Но по какой-то причине это никогда не выполняется. Я также попытался написать сценарий оболочки, который сделал это. .hg / hgrc выглядело так: 

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

и hg-update выглядели так: 

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

Но опять же, это не обновляет. Содержимое hg help записано в works.txt, но ничего не записано для hg update. Есть ли что-то очевидное, что я здесь упускаю? Это мучило меня несколько дней, и я просто не могу заставить его работать.

Обновление

Ладно, еще раз, с помощью переключателя -v в командной строке с моей рабочей станции, отправляющего на удаленный репозиторий, не выводится подробное сообщение, даже если у меня есть эти echo строки в .hg/hgrc. Однако, когда я делаю push от клона репозитория в той же файловой системе (я вошел в систему через SSH), это то, что я получаю: 

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

Так оно и работает, но опять же только когда я нажимаю с той же файловой системы Это не сработает, если я попытаюсь перейти в репозиторий с другой рабочей станции по сети.

Ответы [ 9 ]

10 голосов
/ 03 сентября 2010

Я провел некоторое время, исследуя это сам. Я думаю, что ответ на проблему описан кратко здесь :

Вывод должен быть перенаправлен на stderr (или / dev / null), потому что stdout используется для потока данных.

По сути, вы не перенаправляете на stderr и, следовательно, не загрязняете stdout.

10 голосов
/ 02 февраля 2010

Что ж, пройдя те же самые шаги разочарования, что и Марк W некоторое время назад, я наконец нашел решение проблемы, по крайней мере, когда удаленное обслуживание выполняется с помощью сценария hgwebdir WSGI.

Я обнаружил, что при использовании такого типа удаленной отправки через HTTP или HTTPS, Mercurial просто игнорирует все, что вы пишете в файл .hg / hgrc или в ваш репозиторий. Однако ввод хука в конфиге hgwebdir делает свое дело.

Так что если нижняя строка в вашем hgwebdir.wsgi сценарии похожа на 

application = hgwebdir('hgweb.config')

раздел конфигурации [hooks] должен перейти в упомянутый hgweb.config .

Один недостаток заключается в том, что эти ловушки выполняются для каждого репозитория , указанного в разделе [paths] этой конфигурации. Несмотря на то, что HG предлагает другую функцию с поддержкой WSGI (hgweb вместо hgwebdir) для обслуживания только одного репозитория, кажется, что он не поддерживает никаких хуков (и при этом у него нет никакой конфигурации). Это, однако, можно обойти, используя hgwebdir, как описано выше, и с помощью некоторого Apache RewriteRule отображает все в нужный подкаталог. Этот работает для меня: 

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

Получайте удовольствие, используя удаленные перехватчики по HTTP: D

3 голосов
/ 15 августа 2011

Моя проблема заключалась в том, что мое приложение hgwebdir запускалось от имени пользователя "hg", но хранилище принадлежало мне, поэтому мне пришлось добавить этот бит конфигурации в hgweb.config, чтобы он запускал ловушки: 

[trusted]
users = me
3 голосов
/ 17 мая 2009

Прежде всего, я хочу исправить несколько комментариев выше.

  • Хуки также вызываются при нажатии на файловую систему.
  • Нет необходимости держать крючок в репо, на котором вы хотите, чтобы он работал. Вы также можете написать тот же хук, что и в вашем вопросе на стороне пользователя. Вы должны изменить событие с группы изменений на исходящее, а также указать URL удаленного репо с помощью ключа -R. Затем, если пользователь, выполняющий подталкивание, обладает достаточными привилегиями для удаленного репо, ловушка выполнится успешно.

.hg / hgrc 

[hooks]
outgoing = hg update -R $HG_URL

Теперь к вашей проблеме .... Я предлагаю создать как prechangegroup, так и changegroup hooks и распечатать некоторые отладочные данные.

.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`"

А также нажмите переключатель -v, чтобы вы могли знать, какой хук работает. Если вы все еще не можете понять, опубликуйте результаты. Я мог бы помочь.

2 голосов
/ 20 октября 2010

У меня возникла та же проблема при отправке из Windows Eclipse через http, но после захвата stderr я обнаружил, что необходим полный путь к файлу hg.bat. Моя секция крючков теперь выглядит так: 

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

Надеюсь, это поможет кому-то еще. SteveT

2 голосов
/ 12 мая 2009

Вы должны иметь его в hgrc репозитория remote . Звучит так, как будто это в вашем местном репо.

Изменить: Это также зависит от того, как вы толкаете. Некоторые методы не вызывают хуков с правой стороны. (ssh делает, я думаю, что HTTP делает, файловая система делает не )

Edit2: Что делать, если вы нажмете «локально» на компьютере удаленного репо. У вас могут быть разные пользователи / права доступа между веб-сервером и hgrc-файлом. (См. [Server] и доверенные директивы для hgrc.)

1 голос
/ 30 мая 2015

Причина, по которой я нашел это, не имеет ничего общего с перенаправлением stdout на stderr. Как вы можете видеть на странице вики, она не указана в текущей версии вики. https://www.mercurial -scm.org / вики / FAQ # FAQ.2FCommonProblems.Any_way_to_.27hg_push.27_and_have_an_automatic_.27hg_update.27_on_the_remote_server.3F

Проблема, которую я обнаружил, составляет около разрешений .

В моей первоначальной настройке у меня был пользователь, скажем, hguser с репо в его доме и скриптом /etc/init.d/hg.init для запуска hg serve. Проблема в том, что hg serve выполнялся root, в то время как большинство файлов в репо относилось к hguser (некоторые из них переключались на root в какой-то момент, но это не будет возражать, так как я исправлю их с chown)

Решение:

  • chown -R hguser:hguser /home/hguser/repo (чтобы исправить ВСЕ файлы, обратно в hguser)
  • запуск su hguser -c "hg serve ..." (в моем случае от /etc/init.d/hg.init)
  • changegroup = hg update -C под [hooks] в repo/.hg/hgrc как обычно

Теперь он должен работать на push

PS: в моем случае я скорее обновляюсь до заголовка определенной ветви, поэтому я использую hg update -C -r staging, чтобы промежуточный сервер обновлялся только до заголовка предполагаемой ветви, даже если tip от другая ветвь (например, development)

Кстати, мой hg.init скрипт закончился так: (обратите внимание на su hguser часть) 

#!/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: причитающийся кредит http://jf.blogs.teximus.com/2011/01/running-mercurial-hg-serve-on-linux.html

1 голос
/ 08 ноября 2010

заняло некоторое время, но у меня все заработало.

Я начал с 

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

> & 2 передает это к стандартной ошибке, так что удаленные консоли покажут это.

при удалении должен выводиться на консоль, если он работает 

hg push https://host/hg   -v

Не было.

Я использовал hgweb.cgi, поэтому без разницы переключился на hgweb.wsgi.

я обнаружил, что некоторые хуки не вызываются удаленно.

когда я переключил его на 

[hooks]
incoming= set >&2

теги hooks и commit не вызываются, но вызываются входящие и changeset. Я не подтвердил другие.

теперь, когда все заработало, я вернулся к hgweb.cgi и все работает так же.

1 голос
/ 11 мая 2009

Попробуйте включить отладку хука , чтобы понять, почему он не работает.

Вероятно, проблема с разрешениями или что-то в этом роде.

...