Написание PHP Git Hooks со статическим обзором

canReview , как следует из названия, определяет, можно ли запустить review , и review выполняет реальную рецензию. Возьмите ComposerLintReview.php в качестве примера, который вы можете увидеть ниже. canReview() проверяет, называется ли проверяемый файл composer.json . Если так, то review() может быть вызван.

Затем создается команда, которая вызывает функцию проверки Composer в composer.json и передает ее в метод getProcess , реализованный в AbstractReview , для запуска процесса. Если процесс не успешен, сообщение об ошибке создается и устанавливается для объекта Reporter, передавая его вызову метода error() Reporter, а также файлу, который был просмотрен.

 public   function  canReview ( FileInterface  $file ) 
 { 
     // only if the filename is "composer.json" 
     return   ( $file -> getFileName ()   ===   'composer.json' ); 
 } 

 public   function  review ( ReporterInterface  $reporter ,   FileInterface  $file ) 
 { $cmd =  sprintf ( 'composer validate %s' ,  $file -> getFullPath ()); $process =  $this -> getProcess ( $cmd ); $process -> run (); 

     if   (!  $process -> isSuccessful ())   { $message =   'The composer configuration is not valid' ; $reporter -> error ( $message ,  $this ,  $file ); 
     } 
 } 

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

Пользовательский отзыв

Если вы vendor/sjparkinson/static-review/src/Review/ , то увидите, что существует довольно много готовых классов Review. Они охватывают Composer, PHP и обзоры общего назначения. Но что, если мы захотим создать его сами, который подойдет для нашего конкретного случая использования?

Что если мы обеспокоены тем, что можем оставить операторы var_dump в нашем коде? Мы бы не стали, верно? Но эй, никогда не бывает больно, потому что старые привычки могут иногда сильно умирать. Так как же будет выглядеть пользовательский отзыв? Давайте проработаем один и узнаем.

Сначала мы создадим новую структуру каталогов для хранения нашего кода, совместимого с PSR-4 . Используйте следующую команду в корневом каталоге проекта.

 mkdir - p src / SitePoint / StaticReview / PHP 

Затем в composer.json добавьте следующее в существующую конфигурацию и запустите composer dumpautoload :

 "autoload" :   { 
   "psr-4" :   { 
     "SitePoint\\" :   "src/SitePoint/" 
   } 
 } 

Это обновит автозагрузчик Composer, чтобы также автоматически загружать наше новое пространство имен. После этого создайте новый класс с именем VarDumpReview.php в src/SitePoint/StaticReview/PHP . В него добавьте следующий код:

 <? php namespace   SitePoint \StaticReview\PHP ; 

 use   StaticReview \File\FileInterface ; 
 use   StaticReview \Reporter\ReporterInterface ; 
 use   StaticReview \Review\AbstractReview ; 

 class   VarDumpReview   extends   AbstractReview 
 { 
     public   function  canReview ( FileInterface  $file ) 
     { $extension =  $file -> getExtension (); 
         return   ( $extension ===   'php'   ||  $extension ===   'phtml' ); 
     } 

     public   function  review ( ReporterInterface  $reporter ,   FileInterface  $file ) 
     { $cmd =  sprintf ( 'grep --fixed-strings --ignore-case --quiet "var_dump" %s' ,  $file -> getFullPath ()); $process =  $this -> getProcess ( $cmd ); $process -> run (); 

         if   ( $process -> isSuccessful ())   { $message =   'A call to `var_dump()` was found' ; $reporter -> error ( $message ,  $this ,  $file ); 
         } 
     } 
 } 

Основанный на PhpLintReview.php и ComposerLintReview.php , canReview проверяет, является ли проверяемый файл на основе расширения файлом PHP. Если да, то review использует grep для сканирования файла на наличие ссылок на var_dump .

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

Создание Крюка

Остался только один последний шаг — создание Git-хука из нашего класса хуков. В новой директории Hooks в корне моего проекта я скопировал код хука, с которым мы работали в начале статьи, сделав одно небольшое изменение.

Я добавил наш новый файл обзора в список отзывов следующим образом:

 $review -> addReview ( new   LineEndingsReview ()) 
        -> addReview ( new   PhpLeadingLineReview ()) 
        -> addReview ( new   NoCommitTagReview ()) 
        -> addReview ( new   PhpLintReview ()) 
        -> addReview ( new   ComposerLintReview ()) 
        -> addReview ( new   VarDumpReview ()); 

После этого создайте ловушку перед фиксацией, выполнив следующую команду.

 ./ vendor / bin / static - review . php hook : install hooks / example - pre - commit . php . Git / hooks / pre - commit 

И с этим, если вы посмотрите в .git/hooks , вы увидите символическую ссылку, созданную из pre-commit, в наш новый файл hooks. Чтобы проверить ловушку, сделайте вызов var_dump() в любом файле PHP, var_dump() файл в очередь и var_dump() его зафиксировать.

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

Завершение

И это все, что нужно для создания простых или мощных хитов Git с использованием одного из самых универсальных языков PHP. Я только столкнулся со Статическим Обзором благодаря постоянно бдительному Бруно Скворчу. Но я очень благодарен, что он предложил проверить это.

Теперь я могу выполнить еще одну, очень важную задачу разработки, используя мой любимый язык разработки программного обеспечения — PHP. Вы уже используете Static Review? Если это так, поделитесь своим опытом в комментариях. Мне интересно знать, как люди, более опытные, чем я, используют это.