Git: предварительный прием с помощью PHP_CodeSniffer

Поскольку при переключении с SVN на Git мы потеряли способность применять наши стандарты кодирования с помощью крюка pre-commit на сервере subversion.

С помощью Git у вас есть только предварительные фиксации на клиенте, которые не могут быть применены каким-либо образом. Хуже всего то, что у нас есть разработчики, работающие со всеми тремя основными операционными системами, поэтому привязка pre-commit, работающая в Linux или OS X, не работает автоматически в Windows.

В пути используется реализация pre-receive hook на сервере, но решение не так просто, как кажется:

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

Итак, нам нужен крюк pre-receive, который генерирует список всех измененных файлов во всех коммитах, которые будут помещаться, и запускает phpcs только в текущем состоянии.

Есть ли такой крючок script уже? Где?

Изменить: Кажется, есть script, который создает этот список файлов - к сожалению, в Python, но это можно портировать. Меня все еще интересуют предварительные решения с PHPCS:)

ОТВЕТЫ

Ответ 1

Теперь мы используем крючки с предварительной фиксацией, которые проверяют код и сообщение фиксации.

Разработчики могут пропустить их с помощью -n, но они редко делают, и у нас всегда есть другой разработчик, выполняющий QA, поэтому все замечается.

Крюк важен, потому что он замечает, что файлы повреждены, так что сломанный PHP или JS вообще не фиксируется.

Найдите код крюка в https://github.com/netresearch/git-client-hooks

Мы используем центральный сервер для разработки, и наши крючки git автоматически устанавливаются, потому что мы предоставляем центральный шаблон репозитория git, который автоматически используется, когда вы git clone или git init.

Ответ 2

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

Вы можете настроить промежуточное репо, которое будет регулярно загружать каждую ветвь разработчика и проверять каждый новый коммит, отправляя электронное письмо, если коммит не отвечает некоторым заранее определенным критериям.

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

Ответ 3

Я не выгляжу хорошо 'git -anese', но в Mercurial есть опция hook, называемая "changegroup", которая в основном проверяет "верхнюю" фиксацию группы входящих коммитов. Может быть, кто-то из сообщества может сказать вам, есть ли equiv. "changegroup" для git?

https://www.mercurial-scm.org/wiki/Hook#The_changegroup_hook

Ответ 4

Я не думаю, что здесь есть техническое решение, но если вы действительно хотите беспокоить людей, тогда интегрируйте phpcs в свою настройку CI и начните открывать для него билеты в своем диспетчере проблем.; -)

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

В целом, я понимаю важность стандарта кодирования, и я также применяю его, но там есть социальный компонент (или аспект).

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

Возможно, это требует, чтобы управление проектами (я понял, что вы) разбивает проблему на несколько задач, пока не получит ее:

  • функция
  • phpcs
  • документация
  • блок-тесты

(Без определенного порядка. -))

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

Ответ 5

В проекте Drupal мы недавно перешли на Git и рассматриваем аналогичные проблемы. В нашем случае мы не хотим, чтобы кто-либо просматривал файл LICENSE.txt для модуля, так как наши сценарии упаковки делают это автоматически. После того, как мы продвигались вперед, то, что мы придумали, было крюком приема, который не отклоняет плохую фиксацию, но каждый раз, когда он обнаруживает плохую фиксацию (для некоторого определения "плохой" ), он автоматически создает критическую ошибку в нашей ошибке трекер. Таким образом, код по-прежнему выполняется, но сопровождающий модуль и соответствующая команда веб-мастеров сразу получают уведомление о том, что что-то не так и должно быть исправлено. Вы также можете просто отправить электронное письмо или отправить твиты или другое другое уведомление, которое вы хотите.

На самом деле мы еще не реализовали это, но что план, над которым мы работаем, как только наша команда разработчиков Git имеет время.: -)

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

Ответ 7

Возможно, ответ на этот вопрос помогает? Git pre-receive hook

Ответ 9

У меня нет точного ответа на этот вопрос напрямую с помощью перехватов/предварительных захватов и т.д.

Я подхожу к этому с другой стороны, запуская CI-сервер, (я использую jenkins), запускающий phpcs, и плагин checkstyle для Jenkins.

Это позволяет мне скомпрометировать сборку и отправить по электронной почте коммиттер на основе отчета контрольной таблицы.

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

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

Это может быть ваш промежуточный сервер, как указано выше. Действия post build могут включать в себя Push для другого репозитория git.

Ответ 10

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

Ответ 11

Я тоже экспериментировал с этим. На данный момент у меня нет кода, но я использовал один из крючков (не предварительно, я думаю, это был обновленный), чтобы сделать временную проверку нового ref. Вы можете ускорить это, получив извлеченное дерево, которое вам нужно обновить, и просто сделав мелкие клоны.

Это позволяет получить доступ ко всему исходному дереву, и вы можете не только запускать CS в файлах, измененных с помощью нажатия, но также запускать тесты устройства или дыма.

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

Ответ 12

Есть ли такой крючок script уже? Где?

В настоящее время доступен метод для запуска PHP-линтеров с помощью git hooks: https://github.com/stevegrunwell/wp-enforcer

Ответ 13

Проверьте этот проект: https://github.com/phpro/grumphp Он не может установить предварительные запросы, но, возможно, разрешит ваши проблемы с перехватом перекрестных ограничений.