Svn pre-commit крючок для checkstyle

Question

Вот мой текущий скрипт оболочки в стиле checkstyle. Это работает нормально, если я фиксирую на TRUNK, но не на филиалах. Я не очень понимаю, почему это не работает. Может кто-нибудь, пожалуйста, помогите мне?

#!/bin/sh

###################################################
#
# Verify Checkstyle
#
###################################################

REPOS="$1"
TXN="$2"

SVNLOOK=/usr/bin/svnlook
JAVA=/opt/ibm/java2-i386-50/bin/java
CHECKSTYLE=/usr/local/checkstyle/checkstyle-all-5.1.jar
TMPDIR=/tmp/$TXN
REPORT=/tmp/$TXN/report
CHECKSTYLE_CONFIG=/usr/local/checkstyle/checkstyle.xml

CHANGED=`$SVNLOOK changed -t "$TXN" "$REPOS" | grep -v "^D" | awk '{print $2}'`
mkdir -p $TMPDIR
for LINE in $CHANGED ; do
    FILE=`echo $LINE | egrep -v Test\\.java$ | egrep -v \\/src\\/test\\/ | egrep -v \\/js\\/ext`
    if [ -n "$FILE" ] ; then
        DIRNAME=`dirname $FILE`
        mkdir -p $TMPDIR/$DIRNAME
        $SVNLOOK cat $REPOS --transaction $TXN $FILE > $TMPDIR/$FILE
    fi
done
$JAVA -jar $CHECKSTYLE -c $CHECKSTYLE_CONFIG -r $TMPDIR > $TMPDIR/tmpfile.checkstyle
X=$?
if [ $X -ne 0 ] ; then
    cat $TMPDIR/tmpfile.checkstyle > /dev/stderr
    rm -Rf $TMPDIR
    exit 1
fi
rm -Rf $TMPDIR

exit 0

Спасибо!

Answer 1

Совет: не делайте этот сценарий пред-фиксации.

• Любой сценарий предварительной фиксации будет удерживать фиксацию до ее завершения. Если я проверю дюжину файлов, сколько времени потребуется для запуска этого скрипта? Когда я впервые попал на компьютер, второе время ответа считалось приемлемым. Теперь, если вы не получите ответ в течение нескольких секунд, люди будут жаловаться.
• Что происходит в тех случаях, когда checkstyle ловит что-то, где это не проблема, или способ, которым разработчик написал это, на самом деле яснее и легче понять, чем что checkstyle настаивает на том, что должно быть? Когда вы используете что-то вроде checkstyle или же findbugs, вы должны понимать, что вы получите несколько ложных срабатываний.

Лучший способ - использовать движок непрерывной сборки, такой как Jenkins. Jenkins может быть настроен на автоматическое начало сборки при каждом коммите. Дженкинс может:

• Автоматически сохранять результаты сборки. Затем вы можете выпустить код непосредственно из Jenkins для тестирования и для ваших клиентов. В конце концов, вы знаете, что те же самые файлы jar/ear/war, которые вы тестировали, те же самые, что и ваши клиенты.
• Автоматически запускать различные тесты, включая:
  • Checkstyle
  • FindBugs
  • Corbertura
  • PMD
  • DRY
  • JUnit
  • Проверьте наличие встроенных предупреждений
  • И десятки других
• Дженкинс сохраняет весь вывод сборки, все сохраненные артефакты и все тесты в красивой и доступной для просмотра веб-странице, доступной любому пользователю.
• Jenkins может интегрироваться в широкий спектр инструментов отслеживания проблем, чтобы вы могли видеть, в чем Jenkins создавал конкретную проблему.

Вам не нужно использовать Дженкинс. Хадсон все еще там. Как и CruiseControl, вы можете использовать TeamCity, Bamboo и десятки других систем непрерывной сборки. Мне нравится Дженкинс, потому что разработка очень активна, и она очень проста в настройке. Мне понадобилось около 30 минут, чтобы загрузить его и запустить мою первую работу, когда я впервые услышал об этом.

Я знаю, что вы спрашивали о вашей предварительной фиксации, и я не хочу походить на продавца (Дженкинс свободен и имеет открытый исходный код, и я не имею никакого отношения к проекту), но делаю что-то настолько сложное, как checkstyle проверьте, что крюк перед фиксацией вызывает проблемы. Использование сервера непрерывной сборки - просто лучший способ решения этой проблемы.

Answer 2

Намек.

Попробуйте сравнить структуру каталогов, которую вы создаете временно (удалите "rm -Rf $TMPDIR").

Возможно, у вас есть различия между стволом и ветвями, как:

Магистраль: /tmp/12/code/file.java

Филиалы: /tmp/br1/12/code/file.java