Публикация новой версии WordPress плагина с помощью Github Actions и SVN
В мире веб-разработки и управления контентом существует множество инструментов, но WordPress остается одним из самых популярных и широко используемых. Однако, чтобы обеспечить стабильную и безопасную работу WordPress сайта, важно регулярно обновлять его и использовать актуальные плагины.
В этой статье мы рассмотрим, как опубликовать новую версию вашего WordPress плагина, используя мощные инструменты, такие как GitHub Actions и SVN (Subversion). Давайте шаг за шагом изучим этот процесс и узнаем, как сделать его более эффективным и удобным для разработчиков и пользователей.
Предположим, что наш плагин уже опубликован в репозитории WordPress со slug’ом test-plugin и версией 1.0.0. Но плагин неожиданно стал популярным и нам нужно организовать работу с кодом, для этого регистрируем github и заливаем код туда. Выпустив версию 1.1.0 мы получаем множество гневных писем, отыскав проблему понимаем, что забыли собрать composer autoloader и перепутали часть файлов, удаляя файлы, которые нужны только для разработки. Конечно это всё можно просто исправить, но вернуть доверие пользователей плагина будет сложнее.
С такой историей я сталкивался не раз и с большими плагинами, и с маленькими. Но можно использовать svn, github и немного bash скриптов для решения проблем с релизом версии плагина. Итак, по порядку:
Оглавление
Польза автоматизации публикации с GitHub Actions и SVN
- Быстрота и эффективность: Автоматизация публикации позволяет ускорить и упростить процесс развертывания и обновления проектов. Это особенно важно для больших проектов или при наличии множества зависимостей, так как она исключает ручную работу и связанные с ней ошибки.
- Консистентность: Автоматизированный процесс обновления гарантирует, что каждая новая версия проекта будет развернута или обновлена одинаково. Это способствует предсказуемости и уменьшает вероятность ошибок, связанных с неправильными конфигурациями или упущенными шагами.
- Уменьшение рисков: Автоматизация публикации уменьшает риск человеческих ошибок. Вручную выполняемые задачи могут быть подвержены опечаткам или забытым шагам, что может привести к сбоям и уязвимостям в системе.
- Время и ресурсы: Автоматизация позволяет сэкономить время и ресурсы, так как не требует постоянного вмешательства человека. Разработчики могут сконцентрироваться на написании кода и разработке, а не на рутинных операциях.
Теперь можем приступить к написанию всех нужных скриптов.
1. Создаем скрипт-сборщик проекта
Для начала организуем сборку проекта. В разработке WordPress плагина часто используются composer и npm зависимости, которые нужно установить и вместе с ними собрать проект. План у нас такой:
- Composer – установить только production пакеты, сгенерировать и автоматизировать autoloader.
- NPM – установить зависимости, запустить сборку, убрать всё лишнее (никаких node_modules на продакшене)
- Bash – все сборка будет проходить в созданном далее скрипте
zip.sh
Переменные для работы:
set -e #Скрипт не будет продолжать работу если возникнет ошибка
DIR=$(pwd)
BUILD_DIR="$DIR/build/test-plugin"Код для сборки composer:
# Установить composer зависимости
# --optimize-autoloader для оптимизации автозагрузчика
# --no-dev игнорировать dev зависимости
# -q без вывода лишней информации
composer install --optimize-autoloader --no-dev -qКод для сборки npm:
# Установить npm зависимости
if [ ! -d "./node_modules" ];
then
# npm ci для установки зависимостей по файлу package-lock.json
npm ci --ignore-scripts
fi
# Запустить сборку
npm run buildОсталось только собрать все файлы в одно место, в моем случае набор файлов такой:
FILES=(assets includes templates vendor readme.txt test-plugin.php)А копировать будем так:
for file in ${FILES[@]}; do
cp -R $file $BUILD_DIR
doneТеперь собранный плагин находится в директории BUILD_DIR. Код скрипта целиком можно посмотреть здесь. Данный скрипт можно и нужно менять под себя, здесь главное понять, что сборку проекта можно автоматизировать bash скриптом, а этот скрипт уже можно будет запустить в Github actions.
2. Создаем скрипт для публикации проекта в svn
Теперь в директории /build/test-plugin находится собранный плагин, готовый к публикации, осталось отправить его в SVN репозиторий. Для этого мы создадим еще один bash скрипт svn_push.sh:
# Завершить выполнение при возникновении ошибки
set -e
# Переменные
PLUGIN_SLUG="test-plugin" # Заменить на slug своего плагина
SVN_REPO="https://plugins.svn.wordpress.org/$PLUGIN_SLUG"
NEW_TAG="$1" # Тег новой версии будет передаваться через аргумент вызова скрипта
# ENV Переменные
svn_username="$2"
svn_password="$3"
# Собрать плагин
bash ./bin/zip.sh
# Если локальный svn репозиторий существует, удалить его
rm -rf svn
# Скачать svn репозиторий
svn co "$SVN_REPO" svn
# Удалить код устаревшей версии
rm -rf svn/trunk
# Заменить его на обновленный код
cp -r build/test-plugin svn/trunk
# Перейти в svn директорию
cd svn
# Создать новый тег
svn cp trunk "tags/$NEW_TAG"
# Закрепить изменения в удаленном репозитории
svn ci -m "Publish $NEW_TAG github release" --username "$svn_username" --password "$svn_password"Скачать файл со скриптом можно здесь
Теперь можно запуском одного скрипта собрать плагин и запушить изменения в wordpress.org репозиторий. При запуске плагина нужно передать в него три переменные: новую версию плагина, логин и пароль от wordpress.org вот так:
svn_push.sh 1.1.0 nickname super_secret_password3. Создаем Github action workflow файл для запуска скрипта в github
Есть желание автоматизировать сборку так, чтобы при выпуске релиза на Github’е, релиз сразу же выходил и в wordpress.org репозитории. Это отличный вариант, если вы полностью уверены в своем коде, но с большими проектами не получается быть уверенным всегда. Поэтому используется такая схема:
- Подготовить код и выпустить релиз на Github
- Передать релиз ограниченному кругу пользователей, которые протестируют плагин у себя.
- Внести правки
- Выпустить полноценный релиз
- Запустить обновление кода в wordpress.org репозитории вручную
Для это есть событие workflow_dispatch в github workflow
Создадим файл .github/workflows/release.yml:
# Имя скрипта
name: WordPress Release (SVN)
run-name: Release
# Событие вызова
on:
# Ручной вызов
workflow_dispatch:
# Входные переменные
inputs:
# Одна переменная new tag, которая будет доступна в bash скрипте
new_tag:
description: 'Enter the new tag version (*.*.*)'
required: true
permissions:
contents: write
jobs:
build:
# Код будет запускаться на последней версии ubuntu
runs-on: ubuntu-latest
steps:
# Стандартный скрипт github actions для клонирования репозитория в среду выполнения
- uses: actions/checkout@v3
# Запуск скрипта публикации
- name: Process
env:
# Получение переменных из настроек репозитория
SVN_USERNAME: ${{ secrets.SVN_USERNAME }}
SVN_PASSWORD: ${{ secrets.SVN_PASSWORD }}
# Выдача скрипту всех прав доступа и его запуск
run: |
chmod 777 ./bin/svn_push.sh
sudo bash ./bin/svn_push.sh ${{ github.event.inputs.new_tag }} $SVN_USERNAME $SVN_PASSWORD
shell: bashПосле того как файл будет опубликован в репозитории, можно перейти на вкладку Actions и увидеть скрипт в списке доступных к запуску:
Но запускать action еще рано, ведь у нас не установлены переменные среды, которые отвечают за логин и пароль от репозитория на wordpress.org. Так как эти данные являются приватными, их нельзя публиковать вместе с кодом. Будем использовать Repository secrets
Чтобы их добавить нужно перейти во вкладку “Settings”, открыть сбоку список “Secrets and variables” и перейти в меню “Actions”. Здесь, нажав на кнопку “New repository secret” установим две переменные SVN_PASSWORD и SVN_USERNAME, чтобы получилось как на скриншоте:
Теперь action готов к запуску:
И успешно отработает:
Для того чтобы проверить, что новая версия плагина залита в репозиторий можно просмотреть теги по ссылке https://plugins.svn.wordpress.org/<slug>/tags
Для плагина test_plugin эта страница теперь бы выглядела вот так:
Теперь всё готово для автоматических релизов в wordpress.org
Итог
В итоге, автоматизация публикации новых версий WordPress плагина с использованием GitHub Actions и SVN представляет собой мощный и эффективный способ улучшить процесс разработки и развертывания плагинов. Этот подход обеспечивает высокую степень автоматизации, повышение безопасности и консистентность в проекте, снижает риск человеческой ошибки и повышает общий уровень надежности процесса разработки плагинов для WordPress.
Код из данной статьи можно взять за основу для гораздо более сложного процесса сборки с запуском различных тестов, проверки качества кода и т.п.
Полезные практики
- Не храните учетные данные в открытом виде: Никогда не храните логины и пароли SVN или другие конфиденциальные данные в открытом виде в репозитории GitHub. Используйте секреты GitHub для безопасного хранения конфиденциальных переменных среды.
- Ограничьте доступ к секретам: Убедитесь, что доступ к секретам GitHub ограничен только необходимым пользователям и ролям. Не раскрывайте секреты в журналах выполнения.
- Обновляйте зависимости: Регулярно обновляйте зависимости своего проекта, включая плагины и библиотеки. Это поможет устранить известные уязвимости.
- Тестируйте код перед публикацией: Перед автоматической публикацией новой версии, убедитесь, что плагин успешно прошел тестирование, включая функциональное, безопасность и совместимость с WordPress. О unit тестировании в WordPress вы можете прочитать в двух других наших статьях: в этой и этой
Полезные ссылки
- GitHub Actions Documentation – Официальная документация GitHub Actions:
- Apache Subversion Documentation – Официальная документация SVN:
- Plugin Submission and Promotion – Официальная документация WordPress о публикации плагинов:
Комментирование этой и других статей доступно в нашем Телеграм канале
