GitHub Actions — це фантастичний спосіб запустити робочі процеси безперервної інтеграції, від запуску тестів до перевірки статичного аналізу тощо.
У ваших програмах Laravel дуже важливо запускати процеси робочого процесу, щоб переконатися, що ваш код відповідає певному стандарту. До того, як у нас був конвеєр CI, ми запускали всі ці робочі процеси локально - що викликало проблеми, коли інші забули їх запустити.
У цьому підручнику я розповім про налаштування ваших дій GitHub для ваших програм Laravel, щоб ви могли з радістю сидіти склавши руки та переконатися, що ваш код готовий до запуску.
Початком цього процесу є додавання каталогу в корінь вашого проекту, .github/workflows. Тут ми додаємо наші файли робочого процесу, щоб GitHub міг забрати кожен і запустити його окремо. З цього моменту ви можете спроектувати процеси робочого циклу так, як вони вам потрібні, від окремих робочих циклів для кожної частини - до об'єднання їх усіх в один робочий процес.
Почну з тестового робочого процесу, так як це, швидше за все, для початку. Навіть якщо ви реалізуєте цей один робочий процес, ви зробили крок у правильному напрямку.
Я не буду робити повний огляд того, як ви повинні будувати дії GitHub, оскільки це досить складна тема, яка дуже специфічна для того, як ви хотіли б їх реалізувати. Робочий процес буде вибудовуватися крок за кроком, що дозволить зрозуміти, як це працює. Почнемо з того, що
name: Run tests
on: [push]
нам потрібно дати робочому процесу назву, щось, що GitHub буде використовувати для відображення того, що відбувається. Потім ми додаємо вхід, повідомляючи GitHub, на яких подіях цей робочий процес повинен працювати. Сюди можна додати більше одного, і є широкий спектр подій, які ви можете використовувати.
Наступним нашим кроком є визначення робочих місць, які ми хочемо мати можливість виконувати. Кожен робочий процес може мати в собі кілька завдань. Однак, як правило, я дотримуюся однієї роботи на робочий процес, щоб зробити його простим.
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
Наша робота має назву GitHub, яку можна використовувати як мітку при відображенні того, що відбувається. Нам потрібно визначити, на чому буде працювати ця робота. Тут я використовую ubuntu-laste, оскільки це, як правило, моє цільове розгортання. Тут є багато варіантів, орієнтованих на конкретні версії ОС і навіть різні доступні операційні системи. Потім наша робота має кілька кроків, які потрібно виконати роботі, від перевірки коду до виконання того, що потрібно зробити.
Більшість робочих місць почнуться з акції оформлення замовлення, офіційної акції від команди GitHub. Я використовую тут версію 3, оскільки вона підтримує останню версію вузла для будь-якого JavaScript у моєму проекті. Якщо вам потрібна певна версія вузла, перегляньте примітки до випуску кожної версії, щоб переконатися, що ви відповідаєте вашим вимогам. Далі ми використовуємо
дію shivammathur/setup-php@v2, яку ми використовуємо для налаштування нашого середовища PHP. Проходження в нашій версії PHP та будь-яких розширеннях PHP, необхідних для встановлення.
Потім ми встановлюємо наші залежності PHP, щоб ми могли забезпечити безперебійну установку, коли справа доходить до розгортання пізніше. З кожним кроком ви можете запускати або упаковану дію, або команду CLI, яку можна запустити. Потім ми налаштували наш додаток Laravel, виконуючи будь-які ремісничі команди або щось інше, що нам може знадобитися зробити. У своєму проекті я використовую базу даних SQLite, запущену в пам'яті, для моєї тестової бази даних. Якщо ви використовуєте щось інше, є досить багато доступних варіантів, які добре задокументовані. Все, що я роблю в своєму, це копіюю вказаний файл .env.ci до файлу .env, який буде використовувати програма. Потім ми можемо згенерувати ключ шифрування програми за допомогою ремісничої команди.
Наш останній крок - запустити наш тестовий набір, який я використовую командою ремісничого тесту. Ви можете викликати тест-двійковий сам або скористатися командою ремісника. Ви також можете додати до цієї команди будь-які додаткові опції, які можуть знадобитися для налагодження потенційних тестових збоїв у CI.
Тепер, коли наш початковий робочий процес запущено, ми можемо розглянути ще один. Цього разу ми будемо використовувати один з моїх улюблених робочих процесів для запуску, Статичний аналіз. Як багато людей вже можуть знати, я відвертий розробник, який завжди махає прапором статичного аналізу.
Для цієї наступної частини я не буду знову проходити всі кроки. Замість цього ми зосередимося на фінальній частині.Оскільки нам не
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 для свого статичного аналізу вибору. Однак це буде працювати з будь-якою з доступних бібліотек статичного аналізу. Я передаю прапор формату помилок, щоб будь-які потенційні помилки були у форматі, який GitHub може зрозуміти і призначений для середовища CI.
Ви можете взяти це далі, наприклад, запустити Laravel Pint або більше. Однак, як вступ, я думаю, що це охоплює те, що вам знадобиться.
