Laravel CI совместно с GitHub Action

GitHub Actions — это отличный способ запустить рабочие процессы непрерывной интеграции, от запуска тестов до проверки статического анализа и многого другого.

В приложениях Laravel очень важно запускать рабочие процессы, чтобы гарантировать соответствие вашего кода определенному стандарту. До того, как у нас появился конвейер CI (Continuous Integration), мы запускали все эти рабочие процессы локально, что вызывало проблемы, когда кто-то забывал их запустить.

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

Начало этого процесса — добавить каталог в корень вашего проекта, .github/workflows. Здесь мы добавляем файлы нашего рабочего процесса, чтобы GitHub мог подобрать каждый из них и запустить отдельно. С этого момента вы можете проектировать свои рабочие процессы так, как они вам нужны, от отдельных рабочих процессов для каждой части до объединения их всех в один рабочий процесс.

Начнем с тестового рабочего процесса, так как это наиболее вероятный вариант. Даже если вы внедрите этот один рабочий процесс, будьте уверены - вы сделали шаг в правильном направлении.

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

name: Run tests
 
on: [push]

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

Наш следующий шаг — определить jobs, которые мы хотим запускать. В каждом рабочем процессе может быть несколько jobs. Однако, чтобы упростить рабочий процесс, я как правило придерживаюсь одной задачи на рабочий процесс.

name: Run tests
 
on: [push]
 
jobs:
  tests:
    name: Run tests
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
 
      - name: Setup PHP
        uses: shivammathur/setup-php@v2
        with:
          php-version: '8.2'
          extensions: dom, curl, libxml, mbstring, zip, pcntl, pdo, sqlite, pdo_sqlite, bcmath, soap, intl, gd, exif, iconv
          coverage: none
 
      - name: Run composer install
        run: composer install -n --prefer-dist
 
      - name: Prepare Laravel Application
        run: |
          cp .env.ci .env
          php artisan key:generate
 
      - name: Run tests
        run: php artisan test

У нашего задания job есть имя, которое GitHub использует в качестве метки при отображении происходящего. Нам нужно определить, на чем будет выполняться это задание. Здесь я использую ubuntu-latest, так как это обычное целевое развертывание. Есть много вариантов, ориентированных на определенные версии ОС и даже на разные доступные операционные системы. Затем, наша работа состоит из нескольких шагов, которые необходимо выполнить для запуска, от проверки кода, до непосредственного выполнения того, что нужно сделать.

Большинство jobs начинается с оформления заказа, официального действия команды GitHub. Здесь я использую версию 3, потому что она поддерживает последнюю версию node для любого JavaScript в моем проекте. Если вам нужна конкретная версия node, просмотрите примечания к выпуску каждой версии, чтобы убедиться, что она соответствует вашим требованиям.

Затем мы используем действие shivammathur/setup-php@v2, которое нам необходимо для настройки нашей среды PHP. А именно передаем используемую нами версию PHP и любых расширений PHP, которые необходимо установить.

После устанавливаем наши PHP-зависимости, чтобы обеспечить бесперебойную установку, когда дело дойдет до развертывания в дальнейшем. На каждом этапе вы можете запустить либо пакетное действие, либо команду CLI (Command line interface). Следующим шагом настраиваем наше приложение на Laravel, запускаем любые команды artisan или что-то еще, что нам может понадобиться. В моем проекте я использую базу данных SQLite, работающую в памяти для моей тестовой базы данных. Если вы используете что-то другое, существует довольно много доступных вариантов, которые хорошо задокументированы. Все, что я делаю, это копирую указанный файл .env.ci в файл .env, который будет использовать приложение. Затем мы можем сгенерировать ключ шифрования приложения, используя команду artisan.

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

Теперь, когда наш первоначальный рабочий процесс запущен, можем взглянуть на другой. На этот раз будем использовать один из моих любимых рабочих процессов — статический анализ (Static Analysis). Как многие, возможно, уже знают, я разработчик, который всегда размахивает флагом статического анализа.

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

name: Static Analysis
 
on: [push]
 
jobs:
  phpstan:
    name: phpstan
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
 
      - name: Setup PHP
        uses: shivammathur/setup-php@v2
        with:
          php-version: '8.2'
          coverage: none
 
      - name: Install composer dependencies
        run: composer install -n --prefer-dist
 
      - name: Run Static Analysis
        run: ./vendor/bin/phpstan --error-format=github

Поскольку нам не нужно запускать приложение, нам и не нужно беспокоиться обо всех зависимостях PHP. Наш последний шаг — запустить сам статический анализ. Лично я для этого использую PHPStan. Тем не менее, это будет работать с любой из доступных библиотек статического анализа. Флаг error-format, передается для того чтобы любые потенциальные ошибки были в формате, который может понять GitHub и предназначен для среды CI.

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

Оригинальная статья: https://laravel-news.com/laravel-ci-with-github-action