Когда дело доходит до разработки Drupal, GitHub Actions предлагает неоценимую помощь в автоматизации повторяющихся задач, стандартизации процессов и повышении качества кода. Определяя рабочие процессы как код в файлах YAML, который может реагировать на различные события, он обеспечивает гибкую настройку и масштабируемость. Предварительно созданные действия могут выполнять общие задачи, такие как создание и тестирование кода, а настраиваемые действия можно адаптировать к требованиям конкретного проекта. Давайте рассмотрим некоторые из лучших практик, а также примеры действий, которые вы могли бы использовать в своем следующем проекте Drupal.
Что вы узнаете в этой статье
К концу этой статьи у вас будет полностью оборудованный проект Drupal, который использует действия для автоматизации и обеспечения использования стандартов кодирования Drupal и обнаруживает ошибки до того, как они достигнут рабочей среды, с помощью тестов PHPStan и PHPUnit.
Этот пост посвящен реализации и оптимизации действий в рабочем процессе Drupal. Для более глубокого понимания того, как работает платформа, прочтите документацию.
Почему GitHub Actions?
В основном потому, что он бесплатен как для общедоступных, так и для частных репозиториев (бесплатные учетные записи получают 500 МБ хранилища и 2000 минут в месяц), что делает его доступным для всех разработчиков. Он также обеспечивает обратную связь в режиме реального времени для раннего выявления проблем и позволяет повторно использовать рабочие процессы и действия в нескольких проектах, экономя время и обеспечивая согласованность. У вас могут быть различные проекты Drupal, использующие один и тот же процесс для тестирования, проверки или создания артефакта. Более того, его интеграция с реестром пакетов и контейнеров GitHub предлагает комплексный набор инструментов, которые хорошо соответствуют потребностям проекта Drupal.
Основы
Action
Действие - это многократно используемый фрагмент кода или скрипт, предназначенный для выполнения определенной задачи, такой как установка зависимостей с помощью Composer. Обычно они написаны в формате YAML (и хранятся в файле .github/actions), поэтому их можно легко интегрировать в рабочие процессы, автоматизируя задачи и сокращая время выполнения действий для экономии времени. Они способствуют повторному использованию кода и его сопровождению за счет централизации общей логики, устраняя необходимость изменять каждый рабочий процесс по отдельности при необходимости внесения изменений, таких как изменение версии PHP. Действия служат строительными блоками для построения надежного и мощного рабочего процесса.
Workflow
Рабочие процессы также определяются с использованием синтаксиса YAML и должны храниться в каталоге .github/workflows в вашем репозитории. Ключевым аспектом разработки является определение событий, которые запускают выполнение рабочего процесса. Они включают в себя широкий спектр действий, таких как отправка в репозиторий, события, связанные с запросами на извлечение, комментарии к проблемам и многое другое. Эта настройка позволяет разработчикам обеспечить запуск автоматизированных задач именно тогда, когда это необходимо.
Например, вы можете сохранить минуты времени выполнения в бесплатной учетной записи, не запуская рабочий процесс до тех пор, пока запрос на включение не будет одобрен.
Напрашивается вопрос: зачем кому-то выбирать ручную проверку кода, отнимающую ценные человеко-часы, просто чтобы знать, что после проверки кода тесты все равно могут завершиться неудачей. В этом нет необходимости. Однако у нас есть возможность создавать артефакты для промежуточной среды только после успешного выполнения тестов и одобрения результатов проверки кода. Такой подход гарантирует, что приложение построено на прочной основе, сводя к минимуму риск развертывания ошибочного кода в рабочей среде.
Понимание и настройка триггеров имеет решающее значение для адаптации рабочих процессов в соответствии с конкретными требованиями проекта, обеспечивая эффективную автоматизацию процессов.
Приступим к действию
Наша главная цель - подвергнуть каждый открытый запрос на включение серии оценок, включая PHPCS, анализ PHPStan и тесты PHPUnit. Тем не менее, мы предпочитаем не тестировать черновик запросов на включение. Кроме того, могут быть случаи, когда мы предпочитаем вручную инициировать тесты для запроса на включение перед началом процесса проверки кода. К счастью, у нас есть гибкость для адаптации обоих подходов, убедившись, что наша стратегия тестирования соответствует конкретным потребностям и рабочим процессам нашего проекта.
Для запуска PHPCS, PHPUnit и PHPSTAN необходимые пакеты должны быть перечислены в файле composer.json вашего репозитория, если вы следуете инструкциям. Вы можете запросить пакеты непосредственно в GitHub action, используя глобальный Composer, но мы стремимся использовать настройки, специфичные для проекта. Для этого рекомендуется использовать drupal/core-dev.
Наш рабочий процесс для всех открытых запросов на включение состоит из следующего:
- Запуск настройки PHP с предопределенной версией;
- Проверка composer.json и установка зависимостей;
- Запуск PHPCS, PHPStan и PHPUnit.
Составное действие
(Что такое составное действие?)
Составные действия, являются многоразовыми компонентами в рабочем процессе. Они устраняют необходимость в избыточном коде, тем самым упрощая усилия по техническому обслуживанию. Это действие выполняет две основные задачи:
- Он настраивает PHP с заранее определенной версией (вы можете удобно настроить эту версию с помощью переменных среды GitHub через пользовательский интерфейс).
- Он проверяет composer.json и устанавливает зависимости.
Эта функция полезна для нашего рабочего процесса, так как она позволяет нам использовать пакеты, установленные через Composer позже.
В действии используются входные данные для версии PHP и Composer со значениями по умолчанию:
inputs:
php_version:
description: "Версия PHP для запуска.
default: "8.2"
composer_version:
description: "Версия Composer для запуска."
default: "2"
а затем он выполняет шаги, основанные на этих значениях, перечисленных выше:
runs:
using: "composite"
steps:
- name: Setup PHP
uses: shivammathur/setup-php@v2
with:
# Using the php_version input here.
php-version: ${{ inputs.php_version }}
extensions: gd
- name: Validate composer.json
shell: bash
run: composer validate --no-check-all
- name: Check composer.lock
shell: bash
run: |
composer install --dry-run
if [ $? -ne 0 ]; then
echo "composer.lock is out of date. Please run 'composer update' to generate an updated lock file."
exit 1
fi
- name: Install dependencies via composer
uses: "php-actions/composer@v6"
env:
COMPOSER: "composer.json"
with:
# Using both inputs here.
php_version: ${{ inputs.php_version }}
version: ${{ inputs.composer_version }}
args: "--ignore-platform-reqs --optimize-autoloader"
Рабочий процесс
Он состоит из трех заданий, по одному для каждой из команд:
jobs: run-phpcs: runs-on: ubuntu-latest
# Disabling the job for Draft pull requests.
if: github.event.pull_request.draft == false
# Setting GitHub token to use GitHub CLI.
env: GH_TOKEN: ${{ github.token }}
steps:
- name: Checkout repository
uses: actions/checkout@v4
with: fetch-depth: 0
# Using our custom composite action to run composer checks and composer install.
- name: Composer validate and install
uses: ./.github/actions/composer
id: composer
with: php_version: ${{ env.PHP_VERSION }}
composer_version: ${{ env.COMPOSER_VERSION }}
# We are using phpcs.xml.dist from the project root to determine --extension list, ignores and Drupal,
# DrupalPractice standards.
- name: Run PHPCS on Pull Request Files
run: |
gh pr diff ${{ github.event.number }} --name-only | xargs find 2> /dev/null | xargs vendor/bin/phpcs -nq
Как видно, второй шаг работы PHPCS использует наше ранее определенное пользовательское составное действие, помогая нам в процессе установки пакета, тем самым облегчая использование PHPCS на следующем шаге.
После этого в шаге используется команда gh pr diff, команда GitHub CLI, используемая для проверки измененных файлов в PR (поскольку мы не хотим запускать PHPCS для всех файлов в репозитории). Чтобы включить эту функциональность, мы включили переменную среды GH_TOKEN, необходимую для операций GitHub CLI.
PHPStan
В нашем рабочем процессе мы выполняем команду analyse для всей базы кода, чтобы выявить любые устаревшие версии или ошибки. Хотя можно проанализировать только изменения в PR, для этого примера мы решили проанализировать всю кодовую базу. Однако важно отметить, что этот подход не рекомендуется, особенно для больших репозиториев, из-за того, что он отнимает много времени. В качестве альтернативы, вы можете настроить php stand в файле neon укажите конкретные пути или измените действие на основе примера, приведенного выше, чтобы анализировать только файлы, измененные в ПРОЦЕССЕ.
jobs: run-phpstan:
runs-on: ubuntu-latest
# Disabling the job for Draft pull requests.
if: github.event.pull_request.draft == false
steps:
- name: Checkout repository
uses: actions/checkout@v4
with: fetch-depth: 0
# Using our custom composite action to run composer checks and composer install.
- name: Composer validate and install
uses: ./.github/actions/composer
id: composer
with:
php_version: ${{ env.PHP_VERSION }}
composer_version: ${{ env.COMPOSER_VERSION }}
- name: Run PHPStan analysis
run: vendor/bin/phpstan analyse
PHPUnit
Эта конфигурация направляет скрипт на поиск тестовых файлов соответствующим образом.
jobs: run-phpunit: runs-on: ubuntu-latest
# Disabling the job for Draft pull requests.
if: github.event.pull_request.draft == false
steps: - name: Checkout repository
uses: actions/checkout@v4
with: fetch-depth: 0
# Using our custom composite action to run composer checks and composer install.
- name: Composer validate and install
uses: ./.github/actions/composer
id: composer
with: php_version: ${{ env.PHP_VERSION }}
composer_version: ${{ env.COMPOSER_VERSION }}
# We are using phpunit.xml.dist from the project root to determine the directory of the 'Unit' testsuite,
# in this case 'tests/Unit'.
- name: Run unit tests
run: vendor/bin/phpunit --testsuite Unit
Кроме того, вы можете обнаружить два запроса на включение в репозитории, демонстрируя как неудачное, так и успешное действие для тестов. Эти PR служат демонстрациями, позволяя вам наблюдать, как разворачивается процесс, и понимать основную концепцию.
Заключение
Использование GitHub Actions с Drupal невероятно удобно для пользователя, что делает непрерывную интеграцию и развертывание легким. Это бесплатно в течение заданного количества минут, а возможность повторного использования действий, которыми делится сообщество, экономит время и усилия. Кроме того, GitHub Actions предлагает функциональность для создания артефактов, подходящих для развертывания на хостинге.
