Комментарии 9
Может ли, теоретически, возникнуть противоречие в проверке локально и на сервере? Когда код локально прошел проверку, а на сервере - нет?
Конечно может. Разработчик у себя локально может просто случайно оторвать pre‑commit и локальная проверка вообще не выполнится.
Может, если у тулы есть кэш как, например, у phpstan и psalm. Кэш сильно помогает при большой кодовой базе, но вот такой побочный эффект скорости.
Может, у разработчика используется кеш (например psalm). В CI/CD где выполняют проверки его нет. У нас были случаи когда различались проверки.
Спасибо, очень хорошая статья, тут таких сильно не хватает.
Можете только пояснить логику разбивки на pre-commit и pre-push? Разве не логично проверять синтаксис перед коммитом?
Спасибо за вопрос.
Исходил из того, что pre-commit вызывается чаще, чем pre-push, а значит и более затратные по времени инструменты должны вызываться именно в pre-push. В моем примере на pre-commit вызывается только принудительный форматтер кода по принятому стандарту. Выходит, в моей схеме на pre-commit проверка phpcs вызывается только для перестраховки.
С выводом не соглашусь, т.к. количество проверок только возрастает в итоге, анализаторы в репозитории надо оставлять в любом случае.
Сам привык на пре-коммит настраивать только phpcs или аналог, чтобы явно видеть, где в чем ошибся. Когда автоматически все исправляется phpcbf, то не возникнет привычки писать сразу все правильно отформатированно.
Насчет добавления установки хуков в команды композера - отличная идея?
Двухуровневый CI-процесс PHP-проекта