Двухуровневый CI-процесс PHP-проекта

[dimas846]

Может ли, теоретически, возникнуть противоречие в проверке локально и на сервере? Когда код локально прошел проверку, а на сервере - нет?

[sunlynx]

Конечно может. Разработчик у себя локально может просто случайно оторвать pre‑commit и локальная проверка вообще не выполнится.

[dimas846]

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

[Serganbus]

На моей памяти такого не было. Если проверки и локально и на CI-сервере выполняются на основе одних конфигов, которые лежат вместе с кодом в репозитории, то такого быть не должно.

[olku]

Может, если у тулы есть кэш как, например, у phpstan и psalm. Кэш сильно помогает при большой кодовой базе, но вот такой побочный эффект скорости.

[part_os]

Может, у разработчика используется кеш (например psalm). В CI/CD где выполняют проверки его нет. У нас были случаи когда различались проверки.

[FanatPHP]

Спасибо, очень хорошая статья, тут таких сильно не хватает.

Можете только пояснить логику разбивки на pre-commit и pre-push? Разве не логично проверять синтаксис перед коммитом?

[Serganbus]

Спасибо за вопрос.

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

[GinoPane]

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

Сам привык на пре-коммит настраивать только phpcs или аналог, чтобы явно видеть, где в чем ошибся. Когда автоматически все исправляется phpcbf, то не возникнет привычки писать сразу все правильно отформатированно.

Насчет добавления установки хуков в команды композера - отличная идея👍