2010-12-27 4 views
7

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

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

Что является лучшим способом предотвратить людей, нарушающих сборку с неполными фиксациями?

UPDATE:

Есть примитивный вариант крючка работы, спасибо за всю помощь!

Отрывок из обновлений крючке:

### 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 

(обратите внимание, что это для окружающей среды окна и опирается на ANT_HOME (и, таким образом, JAVA_HOME) переменные среды определяется)

ответ

4

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

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

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

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

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

+6

Компиляция проекта при каждом нажатии может быть чрезмерно дорогой; если да, то «непрерывная интеграция» - это то, что нужно Google. – 9000

+0

+1 для непрерывной интеграции. –

+0

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

1

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

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

+0

+1: Для геррита. И вот живая демонстрация: https://review.source.android.com/ –

Смежные вопросы