Mercurial pre-push hook сканирует рабочую копию

Question

Мне нужно установить хук в репозитории, куда люди могут нажать, что бы выполнить некоторую валидацию (цель состоит в том, чтобы отклонить толчок в случае неудачи валидации) У меня уже есть некоторые настройки для автоматического обновления после успешного нажатия и предотвращения нескольких головок.

У меня нет проблем с написанием сценария проверки (например, сценария оболочки, который запускает модульные тесты), но он должен работать на полной рабочей копии.

Моя проблема в том, что, если я просто помещу его в хук pretxnchangegroup, он не будет работать с обновленными файлами. Если я попытаюсь обновить hg внутри ловушки, это приведет к повреждению хранилища всякий раз, когда проверка завершается неудачно и откат выполняется.

Мое текущее решение состоит в том, чтобы клонировать репозиторий во временную папку и запустить там реальную проверку. Но я нахожу это немного уродливым, и это менее эффективно, чем проверка на месте, выполняющая только обновления. Можно ли настроить этот вид хуков?

Answer 1

Есть способы сделать это, но прежде чем я начну, вы уверены, что хотите это сделать? Выполнение блокирующих, возможно, медленных, отклоняющих push изменений в хуке раздражает людей, и он все время удерживает блокировку записи в хранилище, так что никто больше не может толкать во время выполнения сценария проверки. Можно довольно легко выбросить половину преимуществ производительности DVCS в окно, пытаясь получить небольшой контроль.

Вы можете избежать большинства этих недостатков с помощью двухуровневой настройки репозитория. Что-то вроде project-push, где люди могут нажимать без прохождения проверки, и project-pull, который имеет только наборы изменений, которые прошли некоторую проверку. Затем у вас есть внеполосный (cron или hook-triggered) скрипт, который перемещает наборы изменений с project-push на project-pull только после подтверждения валидации. Поскольку этот тест выполняется вне полосы, нажатия не блокируются, но не проверяющие наборы изменений никогда не превращаются в project-pull. Вы можете отправить его по электронной почте автору, когда его толчок перевел project-pull в состояние без проверки. Пользователям с их .hg/hgrc, настроенными таким образом, вообще не придется думать о том, что они являются двумя репозиториями:

[paths]
default=http://host//path/to/project-pull
default-push=http://host//path/to/project-push

Они могут просто использовать hg push и hg pull, и все будет "просто работать".

Тем не менее, если вашей проверке не требуется доступ ко всем обновленным файлам одновременно, вы можете выполнить тест с помощью чего-то подобного во внешней pretxnchangegroup ловушке:

for thefile in $(hg manifest -r tip) ; do
  if ! hg cat -r tip $thefile | ./validate_on_file.sh ; then
     exit
  fi
done

Если вам нужно работать со всеми файлами одновременно (компиляцией и т. Д.) И вы не желаете создавать структуру с двумя репо, которая освобождает людей для быстрого продвижения, тогда вам нужно отдельное репо для тестирования , но вам не нужно клонировать / создавать его каждый раз. Что-то вроде этого в pretxnchangegroup хуке должно сделать:

hg push /scratch/long-lived-testrepo ## Warning: may not work,  
                                     ## if pretxnchangegroup locks the repo and  
                                     ## blocks this push to testrepo
hg -R /scratch/long-lived-testrepo update
cd /scratch/long-lived-testrepo
./validation.sh