PHP codeniffer (phpcs) - как разрешить переопределение при использовании как части хука предварительной фиксации svn?

Зачем запускать его на предварительной фиксации? Я использовал как PHPUnderControl, так и Hudson для автоматизации "сборки" php... По сути, они запускают скрипт сборки ant/phing, который запускает автоматизированные тесты (PHPUnit) и сканеры качества кода (включая PHPCS) после каждого коммита (определяется автоматически). Таким образом, он не отклонит фиксацию, но отправит приятное электронное письмо тому, кому вы хотите, о том, что сборка не удалась, и укажет, почему (конкретные строки оскорбительного кода)...

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

Во-первых, у нас есть политика «распростертых объятий» при фиксации:

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

Затем у нас есть политика «сжатого кулака» в отношении промежуточных/выпускных сборок:

• Сборка завершается сбоем при любом, даже тривиальном, отклонении от правил, что означает: обязательную корректность синтаксиса, соответствие стандартам, документацию кода и все тесты проходят с честью
• Предотвращает выпуск чего-либо глючного. Если что-то глючит, это проблема с кодом И проблема со сборкой (дыра в процессе, недостаточно тестов и т. д.)

Все это автоматизируется через phing с использованием phpcs (и, конечно же, phpunit, phpdocumentor и т. д.).

Я думаю, что ircmaxell имеет отличную точку зрения - такого рода проверка стандартов должна быть где-то еще, кроме хука перед фиксацией, например. в среде непрерывной интеграции или, в крайнем случае, перехватчик после фиксации и должен быть основан на предоставлении информации, а не на блокировании коммитов!

Имея это в виду, я решил на данный момент использовать подход opt-in. Я настроил хук pre-commit svn, чтобы искать ключевое слово в сообщении фиксации и запускать phpcs, если оно было найдено.

В скрипте ловушки перед фиксацией, например. /var/www/svn/repos/<reponame>/hooks/;

#!/bin/sh

REPOS="$1"
TXN="$2"
SVNLOOK=/usr/bin/svnlook
PHPCS=/usr/bin/scripts/phpcs-svn-pre-commit

if [[ `$SVNLOOK log -t $TXN $REPOS | tr "[:upper:]" "[:lower:]"` =~ "\[?standardcode\]?" ]]; then

  # Run the PHP code sniffer                                                                                                                     
  PHPCS_STRICT=`$PHPCS "$REPOS" -t "$TXN"`
  if [[ $? -ne 0 ]]; then
      echo "$PHPCS_STRICT" >>/dev/stderr
      echo "*** Commit blocked - Please fix coding standard errors." >>/dev/stderr
      exit 1
  fi
fi

exit 0

Примечания:

• Я выбрал ключевое слово [standardcode], а сообщение журнала было преобразовано в нижний регистр, чтобы сделать ключевое слово нечувствительным к регистру.
• Хук фиксации phpcs (/usr/bin/scripts/phpcs-svn-pre-commit) поставляется вместе с phpcs (по крайней мере, в CentOS 5.5).

Идея состоит в том, что разработчик может поместить ключевое слово в сообщение о коммите в качестве своего рода почетного знака, но он не обязан проверять свой код, если он не подходит для его коммита.