Как я могу сделать так, чтобы git отклонял push-код, который не будет компилироваться? - PullRequest
Новая
       19

Как я могу сделать так, чтобы git отклонял push-код, который не будет компилироваться?

8 голосов
/ 27 декабря 2010

Я хотел бы добавить хук обновления для git, который не позволяет людям выдвигать код Java, который не будет компилироваться.В идеале это вызовет javac, увидит результат и разрешит или отклонит push.

Самый распространенный пример того, что я хочу предотвратить, - это то, что кто-то не вносит все свои изменения, тем самым нарушая сборку.Тем не менее, я понимаю, что перехватчики git запускаются на клиенте (а не на сервере), поэтому, если все вышеперечисленное произойдет, перехватчик все равно будет разрешать отправку.

Каков наилучший способ предотвратить нарушение целостности сборки людьми с неполнымкоммиты?

ОБНОВЛЕНИЕ:

Получил примитивную версию работающего хука, спасибо за помощь!

Выдержка из хука обновления: 

### make sure code compiles
## currently does this by copying the state of the repository as of the pushed code and attempting to build it

# for now, hard coded as C:\Windows\Temp
copydir="/c/Windows/Temp/git_hook_compile_copy"

echo "making copy of $newrev to $copydir" >&2
rm -rf "$copydir"
mkdir "$copydir"
git archive $newrev | tar -x -C $copydir/
if [ "$?" != "0" ]; then
    echo "*** unable to make copy of code" >&2
    exit 1
fi
echo "attempting to build $newrev" >&2
"$ANT_HOME/bin/ant" -file "$copydir/appropriatePath/build.xml"
if [ "$?" != "0" ]; then
    echo "*** code does not compile" >&2
    exit 1
fi

(обратите внимание, что это для среды Windows и зависит от определяемых переменных среды ANT_HOME (и, следовательно, JAVA_HOME))

Ответы [ 2 ]

4 голосов
/ 27 декабря 2010

Git-сервер и клиент мало чем отличаются ;-). Поэтому все перехваты, которые запускаются на «клиенте», будут выполняться на «сервере», если, конечно, на сервере происходят одни и те же события.

Например, update hook, полностью попадает в эту категорию. Он вызывается после того, как ветка была обновлена, и если этот хук возвращает ненулевой статус, обновление отменяется. Так что вы можете поместить туда компиляцию и вернуть ее результат. Все сообщения, которые вы печатаете с крючка, будут показаны пользователю, который фиксирует их на своей консоли. Это очень удобно, так как он может видеть сообщения об ошибках из вашего скрипта сборки и исправлять их.

Даже если вы запустили две компиляции одновременно, репозиторий git не потеряет коммиты из-за использования аргумента «старого refname» в своем хуке обновления. Тем не менее, может случиться так, что коммиттер ожидает компиляции, и его реф не будет сдвинут, потому что кто-то другой вместо этого получил его.

Стандартный репозиторий git содержит хороший пример update ловушки (с именем update.sample). Обратитесь к нему, если вам нужен точный пример.

Однако, если компиляция слишком длинная, а скорость коммитов превышает частоту, с которой вы можете скомпилировать код, возможно, вы захотите использовать более продвинутые решения. Комментаторы предлагают искать в Google "непрерывную интеграцию".

1 голос
/ 28 декабря 2010

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

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

...