Построение рабочего процесса CI/CD — автоматическое развертывание темы WordPress с помощью действий GitHub

Введение

В современной веб-разработке часто необходимо выполнить несколько шагов, чтобы создать и развернуть свой код в рабочей среде. Для темы или плагина WordPress это может означать установку зависимостей Composer и/или Node.js, компиляцию CSS, транспиляцию JavaScript и загрузку файлов на ваш сервер.

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

Если вы нажали только на рабочий процесс, прокрутите этот пост до конца и сразу погрузитесь в него. Тем не менее, мы рекомендуем вам прочитать всю статью, где мы подробно объясним, как все работает!

Предпосылки

• Базовое понимание Git (создание репозитория, коммит и отправка кода, создание веток и т. д.)
• Знакомство с интерфейсом GitHub

Что такое «развертывание» в веб-разработке?

Развертывание в веб-разработке — это процесс внесения изменений в удаленную среду, делающий веб-сайт или приложение доступным для использования.

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

Есть много способов передать файлы вашего сайта хостинг-провайдеру. В нашем случае мы будем использовать безопасный протокол передачи файлов (SFTP), который, как следует из названия, представляет собой сетевой протокол для передачи файлов по безопасному каналу, например SSH.

Что такое действия GitHub?

GitHub Actions — это платформа непрерывной интеграции и непрерывной доставки (CI/CD), которая позволяет автоматизировать процесс сборки и развертывания.

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

Промежуточная среда — это предпроизводственная среда для тестирования, которая является почти точной копией производственной среды. Он стремится максимально точно отразить реальную производственную среду, чтобы изменения можно было протестировать в ней, прежде чем они будут применены к производственной среде.

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

Что такое рабочий процесс GitHub Actions?

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

Есть много преимуществ использования рабочего процесса GitHub Actions.

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

Начиная

Давайте начнем с вашего самого первого рабочего процесса, создав новый файл YAML в .github/workflows/ в вашем репозитории GitHub. Мы начнем с простого рабочего процесса для автоматического развертывания в рабочей среде, поэтому давайте назовем этот файл deploy.yml .

 # .github/workflows/deploy.yml name: deploy on: push: branches: # Pushing to the `main` branch # will trigger our workflow - main

Мы используем ключевое слово on , чтобы определить, какие события могут запускать рабочий процесс. В этом примере рабочий процесс запустится при отправке в main ветвь.

Нам, вероятно, вообще не нужно развертывать, когда меняются определенные файлы, например README.md . Мы можем использовать on.push.paths-ignore , чтобы исключить шаблоны путей к файлам.

 name: deploy on: push: branches: - main paths-ignore: - 'bin/**' - 'README.m

Создание вашей первой работы

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

 name: deploy on: [...] jobs: deploy: runs-on: ubuntu-latest steps: [...]

Каждое задание выполняется в среде исполнителя, заданной параметром runs-on . В приведенном выше блоке YAML мы используем ubuntu-latest , которая представляет собой виртуальную машину (ВМ) Ubuntu Linux, размещенную на GitHub с предустановленным приложением для запуска и другими инструментами.

Вы можете использовать средство запуска, размещенное на GitHub, или разместить свои собственные средства выполнения и настроить среду, используемую для запуска заданий. Однако последнее выходит за рамки данной статьи.

Проверка вашего репозитория Git

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

 jobs: deploy: runs-on: ubuntu-latest steps: - name: Checkout # Checkout our repository under `${GITHUB_WORKSPACE}`, # so our workflow can access it uses: actions/checkout@v3 with: # Fetch the entire Git history fetch-depth: 0

Мы указываем fetch-depth 0 , что приведет к выборке всей истории Git. Это нужно нам для загрузки только тех файлов, которые изменились при последующих запусках.

Создание пользователя SFTP

Чтобы загрузить файлы на хостинг-провайдера, вам потребуются данные вашего SFTP-соединения (т. е. хост, сетевой порт и путь) и пользователь SFTP.

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

Если вы уже используете Pressidium, выполните следующие действия:

1. Войдите в личный кабинет Pressidium
2. Выберите пункт меню «Веб- сайты » на боковой панели панели инструментов.
3. Нажмите на название вашего сайта
4. Перейдите на вкладку SFTP , щелкнув ссылку на панели навигации.
5. Запишите данные о вашем SFTP-подключении .
6. Создайте нового пользователя SFTP

Чтобы создать нового пользователя SFTP:

1. Нажмите « Создать ».
2. Выберите среду ( производство или постановка )
3. Укажите имя пользователя и пароль (рекомендуется надежный пароль, смесь строчных и прописных латинских букв, цифр и специальных символов)
4. Запомните имя пользователя и пароль, которые вы ввели
5. Нажмите « Создать» , чтобы создать пользователя.

На втором этапе вы должны выбрать среду, в которой вы хотите выполнить развертывание. В этом примере мы создадим пользователя для каждой среды.

Разместите свой сайт с Pressidium

60- ДНЕВНАЯ ГАРАНТИЯ ВОЗВРАТА ДЕНЕГ

ПОСМОТРЕТЬ НАШИ ПЛАНЫ

Для получения дополнительной информации о доступе к вашему сайту Pressidium WordPress через SFTP обратитесь к этой статье базы знаний.

Хранение конфиденциальной информации

Вы можете ввести данные подключения SFTP и учетные данные пользователя SFTP непосредственно в рабочем процессе GitHub Actions. Однако хранить конфиденциальную информацию в вашем репозитории — плохая идея.

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

Чтобы создать зашифрованный секрет для репозитория:

1. Войдите в свою учетную запись GitHub
2. Перейдите на главную страницу вашего репозитория.
3. Под именем вашего репозитория нажмите Настройки
4. Выберите « Секреты» и нажмите « Действия » в разделе «Безопасность» на боковой панели.
5. Нажмите кнопку Новый секрет репозитория
6. Введите секретное имя и его значение
7. Нажмите Добавить секрет

У вас должен получиться список секретов, похожий на этот:

• SFTP_HOST Имя хоста SFTP-сервера.
• SFTP_PORT Порт SFTP-сервера
• SFTP_USER Имя пользователя для аутентификации
• SFTP_PASS Пароль для аутентификации

Загрузка файлов через SFTP

Чтобы загрузить файлы через SFTP, вы можете использовать — как вы уже догадались — другое действие GitHub.

На выбор предлагается несколько клиентов SFTP и действий GitHub. Мы пошли с нашим собственным lftp-mirror-action , который использует lftp под капотом. Инструмент для передачи файлов, который поддерживает SFTP и может передавать несколько файлов параллельно.

 - name: Deploy via SFTP uses: pressidium/lftp-mirror-action@v1 with: host: ${{ secrets.SFTP_HOST }} port: ${{ secrets.SFTP_PORT }} user: ${{ secrets.SFTP_USER }} pass: ${{ secrets.SFTP_PASS }} remoteDir: '/demo-www/wp-content/themes/my-theme' options: '--verbose'

Настройка входных данных lftp-mirror-action довольно проста:

• Доступ к вашим данным SFTP-соединения и учетным данным пользователя SFTP можно получить через контекст secrets (например ${{ secrets.SFTP_HOST }} )
• remoteDir — это путь к каталогу вашей темы.
• Опция '--verbose' включает подробный вывод, который будет регистрировать все передачи файлов (полезно для устранения неполадок).

В Pressidium пути форматируются следующим образом:

• YOUR_INSTALLATION_NAME-www/ в качестве корневого пути рабочей среды.
• YOUR_INSTALLATION_NAME-dev-www/ в качестве корневого пути промежуточной среды.

где YOUR_INSTALLATION_NAME — это имя вашей установки. Обратите внимание, что у владельца учетной записи есть учетная запись SFTP, отображаемая как «основная» учетная запись, которая имеет доступ ко всем веб-сайтам, поэтому их пути будут отличаться от указанных выше. Рекомендуется избегать использования этой учетной записи и вместо этого создавать отдельную учетную запись для каждого веб-сайта, к которому вы хотите получить доступ.

При желании вы можете создать файл .lftp_ignore в своем репозитории, включая любые шаблоны файлов, которые вы хотите исключить из развертывания.

Вот пример того, как это может выглядеть:

 ## Directories to ignore .vscode/** .env.** .git/ .github/ ## Files to ignore .gitignore package.json package-lock.json composer.json composer.lock

Собираем все вместе

 name: deploy on: push: branches: - main paths-ignore: - 'bin/**' - 'README.md' jobs: deploy: runs-on: ubuntu-latest steps: - name: Checkout uses: actions/checkout@v3 with: fetch-depth: 0 - name: Deploy via SFTP uses: pressidium/lftp-mirror-action@v1 with: host: ${{ secrets.SFTP_HOST }} port: ${{ secrets.SFTP_PORT }} user: ${{ secrets.SFTP_USER }} pass: ${{ secrets.SFTP_PASS }} remoteDir: '/demo-www/wp-content/themes/my-theme' options: '--verbose'

Вот и все! Теперь ваш рабочий процесс может автоматически развертывать вашу тему WordPress.

Создание и развертывание вашей темы WordPress

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

В качестве примера настройки мы будем использовать репозиторий GitHub с двумя ветками:

• стабильная, готовая к работе main ветка, которая будет развернута в производственной среде
• непроверенная preview ветка, которая служит веткой интеграции для функций и будет развернута в промежуточной среде.

Пришло время ввести задание build и переименовать наш рабочий процесс в build-deploy , поскольку он будет отвечать за сборку и развертывание нашего кода.

 name: build-deploy on: push: branches: - main paths-ignore: - 'bin/**' - 'README.md' jobs: build: runs-on: ubuntu-latest steps: [...] deploy: [...]

Проверка вашего репозитория Git

Каждое задание запускается в новом экземпляре образа исполнителя, поэтому вам нужно еще раз проверить свой репозиторий GitHub в задании build .

 build: runs-on: ubuntu-latest steps: - name: Checkout uses: actions/checkout@v3

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

Установка зависимостей

Некоторые темы используют сторонние пакеты и библиотеки. Если для вашей темы требуются какие-либо пакеты PHP и/или JavaScript, вы можете использовать менеджер пакетов, например Composer, npm или yarn.

Для этого примера мы предположим, что вам нужно установить зависимости Composer и Node.js. К счастью для нас, для этого есть готовые действия.

 steps: - name: Checkout uses: actions/checkout@v3 - name: Install Composer dependencies uses: php-actions/composer@v6 - name: Install Node.js LTS uses: actions/setup-node@v3 with: node-version: 'lts/*' cache: 'yarn' - name: Install Node.js dependencies run: yarn install

Действие композитора по умолчанию запускает composer install , поэтому вам не нужно настраивать какие-либо его входные параметры.

Для действия setup-node мы устанавливаем пользовательские значения для версии node-version и входных данных cache , чтобы указать, что мы хотим:

• получить долгосрочную поддержку (или LTS) версию Node.js
• кешировать любые зависимости, полученные через менеджер пакетов пряжи

Затем следующим шагом будет запуск yarn install для установки зависимостей Node.js. Помните, что шаг может запускать скрипт или действие GitHub.

Обратите внимание, что кэширование может значительно ускорить ваш рабочий процесс. Загрузка зависимостей каждый раз при запуске вашего рабочего процесса приведет к увеличению времени выполнения. Вы можете кэшировать зависимости для задания с помощью действия cache (это то, что действие setup-node также делает под капотом), ускоряя время, необходимое для повторного создания файлов.

Запуск процесса сборки

Опять же, мы предположим, что вам нужно выполнить процесс «сборки» — вам может понадобиться запустить препроцессор для компиляции ваших таблиц стилей, транспиляции ваших скриптов ES6+ и т. д. Обычно это означает, что вы определили скрипт build в своем файл package.json .

Итак, вам понадобится еще один шаг, чтобы запустить этот процесс сборки.

 - name: Build theme run: yarn run build

Если вам нужно запустить разные сценарии для main ветки и ветки preview (например, build для main ветки и staging для preview ), вы можете сделать это следующим образом:

 - name: Build theme run: | if [[ "${{ github.base_ref }}" == "main" || "${{ github.ref }}" == "refs/heads/main" ]]; then yarn run build else yarn run staging fi

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

Артефакты

Артефакты позволяют сохранять данные после завершения задания, поэтому вы можете обмениваться данными между заданиями в рабочем процессе.

Давайте представим дополнительный шаг к вашему заданию build , чтобы сохранить данные, созданные на этапах сборки, с периодом хранения 1 день, используя действие Upload-Artifact . Предположим, что Composer устанавливает свои зависимости в каталог vendor/ , а наш скрипт build экспортирует файлы в каталог dist/ .

 - name: Upload artifact uses: actions/upload-artifact@v3 with: name: my-theme-build path: | dist/ vendor/ retention-days: 1

В зависимости от размера вашего репозитория и частоты отправки вы можете ознакомиться с ограничениями использования, выставлением счетов и администрированием GitHub.

На момент написания статьи GitHub по умолчанию хранит журналы сборки и артефакты в течение 90 дней и предоставляет 500 МБ хранилища в плане «GitHub Free».

Последовательное выполнение заданий

Рабочий процесс состоит из одного или нескольких заданий, которые по умолчанию выполняются параллельно. В нашем случае мы должны создать нашу тему, прежде чем мы сможем ее развернуть. Для последовательного запуска заданий build и deploy необходимо определить зависимость с помощью ключевого слова jobs.<job_id>.needs .

 deploy: runs-on: ubuntu-latest needs: build

В приведенном ниже примере мы указываем, что задание build должно быть успешно завершено, прежде чем можно будет запустить задание deploy .

 name: build-deploy on: [...] jobs: build: runs-on: ubuntu-latest steps: [...] deploy: runs-on: ubuntu-latest needs: build steps: [...]

Загрузка артефакта

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

 - name: Download artifact uses: actions/download-artifact@v3 with: name: my-theme-build path: .

Вы можете использовать действие Download -Arti fact аналогично Upload-Artifact . Убедитесь, что вы указали одно и то же имя — в данном случае my-theme-build — для обоих действий.

Собираем все вместе

 name: build-deploy on: push: branches: - main paths-ignore: - 'bin/**' - 'README.md' jobs: build: runs-on: ubuntu-latest steps: - name: Checkout uses: actions/checkout@v3 - name: Install Composer dependencies uses: php-actions/composer@v6 - name: Install Node.js LTS uses: actions/setup-node@v3 with: node-version: 'lts/*' cache: 'yarn' - name: Install Node.js dependencies run: yarn install - name: Build theme run: | if [[ "${{ github.base_ref }}" == "main" || "${{ github.ref }}" == "refs/heads/main" ]]; then yarn run build else yarn run staging fi - name: Upload artifact uses: actions/upload-artifact@v3 with: name: my-theme-build path: | dist/ vendor/ retention-days: 1 deploy: runs-on: ubuntu-latest needs: build steps: - name: Checkout uses: actions/checkout@v3 with: fetch-depth: 0 - name: Download artifact uses: actions/download-artifact@v3 with: name: my-theme-build path: . - name: Deploy via SFTP uses: pressidium/lftp-mirror-action@v1 with: host: ${{ secrets.SFTP_HOST }} port: ${{ secrets.SFTP_PORT }} user: ${{ secrets.SFTP_USER }} pass: ${{ secrets.SFTP_PASS }} remoteDir: '/demo-www/wp-content/themes/my-theme' options: '--verbose'

Теперь у вас есть рабочий процесс GitHub Actions, который может автоматически создавать и развертывать ваш код в рабочей среде при отправке в main ветку! Однако в начале этой статьи мы описали рабочий процесс, который можно развернуть как в рабочей, так и в промежуточной среде, в зависимости от ветки, в которую вы выполняете отправку. Если вы все еще готовы к этому, просто продолжайте читать!

Развертывание вашей темы в нескольких средах

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

Итак, давайте создадим разные секреты для имени пользователя/пароля каждого пользователя. Это означает, что наш обновленный список зашифрованных секретов должен выглядеть так:

• SFTP_HOST
• SFTP_PORT
• SFTP_PROD_USER
• SFTP_PROD_PASS
• SFTP_STAG_USER
• SFTP_STAG_PASS

Возможно, вам также придется обновить хост и сетевой порт. Хотя в данном случае менять их не нужно, так как они идентичны для обеих сред.

Установка переменных окружения

Переменная среды — это переменная, состоящая из пары имя/значение и являющаяся частью среды, в которой выполняется процесс.

В рабочем процессе GitHub Actions вы можете использовать ключевое слово env , чтобы установить пользовательскую переменную среды, область действия которой:

• Весь рабочий процесс с использованием env на верхнем уровне рабочего процесса.
• Задание в рабочем процессе с использованием env на уровне этого задания.
• Конкретный шаг в задании с использованием env на уровне этого шага

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

Как видите, существует несколько способов построения рабочих процессов. Итак, не стесняйтесь использовать то, что имеет для вас наибольший смысл.

В нашем случае мы устанавливаем переменные среды на шаге задания для временного хранения значений и доступа к ним с другого шага, который выполняется позже в нашем рабочем процессе. Мы добавим переменные среды в $GITHUB_ENV в шагах, которые выполняются для push -событий в определенные ветки, чтобы продемонстрировать, как вы можете условно устанавливать свои пользовательские переменные.

 - name: Set environment variables (main) if: github.ref == 'refs/heads/main' run: | echo "SFTP_USER=${{ secrets.SFTP_PROD_USER }}" >> $GITHUB_ENV echo "SFTP_PASS=${{ secrets.SFTP_PROD_PASS }}" >> $GITHUB_ENV echo "DEPLOY_PATH=/demo-www/wp-content/themes/my-theme" >> $GITHUB_ENV - name: Set environment variables (preview) if: github.ref == 'refs/heads/preview' run: | echo "SFTP_USER=${{ secrets.SFTP_STAG_USER }}" >> $GITHUB_ENV echo "SFTP_PASS=${{ secrets.SFTP_STAG_PASS }}" >> $GITHUB_ENV echo "DEPLOY_PATH=/demo-dev-www/wp-content/themes/my-theme" >> $GITHUB_ENV

Мы используем ключевое слово if чтобы ограничить каждый шаг определенной ветвью. Таким образом, установка переменных среды (основная) будет выполняться только в том случае, если изменения были отправлены в main ветку.

$DEPLOY_PATH также может отличаться для каждой среды.

Например, на Pressidium:

• Пути для производственных сред имеют формат /<WEBSITE_NAME>-www/
• Пути для промежуточных сред имеют формат /<WEBSITE_NAME>-dev-www/

Настройка выходов

Мы хотели бы использовать переменные среды, которые мы только что установили, в качестве входных данных для действия GitHub, которое будет передавать файлы через SFTP.

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

 - name: Set outputs # Workaround to reference environment variables as inputs # using step outputs, since we can't pass environment # variables as inputs at the moment. id: sftp_details run: | echo "user=${SFTP_USER}" >> $GITHUB_OUTPUT echo "pass=${SFTP_PASS}" >> $GITHUB_OUTPUT echo "deploy_path=${DEPLOY_PATH}" >> $GITHUB_OUTPUT

Теперь у вас есть выходные данные user , pass и deploy_path для шага sftp_details , которые вы можете использовать для ссылки на эти значения в качестве входных данных для следующего шага.

Загрузка файлов в разные среды

Загрузка файлов через SFTP почти такая же, как и раньше, но вместо ссылки на контекст secrets и жесткого кодирования remoteDir вы будете использовать выходные данные предыдущего шага.

 - name: Deploy via SFTP uses: pressidium/lftp-mirror-action@v1 with: host: ${{ secrets.SFTP_HOST }} port: ${{ secrets.SFTP_PORT }} user: ${{ steps.sftp_details.outputs.user }} pass: ${{ steps.sftp_details.outputs.pass }} remoteDir: ${{ steps.sftp_details.outputs.deploy_path }} options: '--verbose'

Используйте ${{ steps.<step_id>.outputs.<output_name> }} , чтобы получить доступ к выходным данным шага. Например, ${{ steps.sftp_details.outputs.user }} для доступа к user выходу шага sftp_details .

Фу, наконец! Теперь ваш рабочий процесс может создавать и развертывать вашу тему WordPress как в рабочей, так и в тестовой среде.

Объединение всего рабочего процесса

 name: build-deploy on: push: branches: # Pushing to any of the following # branches will trigger our workflow - main - preview paths-ignore: # When all the path names match patterns in `paths-ignore` # the workflow will not run. We don't want to do anything # if we have changed *only* (some of) these files - 'bin/**' - 'README.md' jobs: build: runs-on: ubuntu-latest steps: - name: Checkout # Checkout our repository under `${GITHUB_WORKSPACE}`, # so our workflow can access it uses: actions/checkout@v3 - name: Install Composer dependencies # This will run `composer install` # since that's its default command uses: php-actions/composer@v6 - name: Install Node.js LTS # We use the LTS version of Node.js # and cache packages installed via yarn uses: actions/setup-node@v3 with: node-version: 'lts/*' cache: 'yarn' - name: Install Node.js dependencies run: yarn install - name: Build theme # Run the `build` script for production, # and the `staging` script for staging run: | if [[ "${{ github.base_ref }}" == "main" || "${{ github.ref }}" == "refs/heads/main" ]]; then yarn run build else yarn run staging fi - name: Upload artifact # Persist data produced during the build steps # with a retention period of 1 day uses: actions/upload-artifact@v3 with: name: my-theme-build path: | dist/ vendor/ retention-days: 1 deploy: runs-on: ubuntu-latest needs: build steps: - name: Checkout uses: actions/checkout@v3 with: # Fetch the entire Git history fetch-depth: 0 - name: Download artifact uses: actions/download-artifact@v3 with: name: my-theme-build path: . - name: Set environment variables (main) if: github.ref == 'refs/heads/main' run: | echo "SFTP_USER=${{ secrets.SFTP_PROD_USER }}" >> $GITHUB_ENV echo "SFTP_PASS=${{ secrets.SFTP_PROD_PASS }}" >> $GITHUB_ENV echo "DEPLOY_PATH=/demo-www/wp-content/themes/my-theme" >> $GITHUB_ENV - name: Set environment variables (preview) if: github.ref == 'refs/heads/preview' run: | echo "SFTP_USER=${{ secrets.SFTP_STAG_USER }}" >> $GITHUB_ENV echo "SFTP_PASS=${{ secrets.SFTP_STAG_PASS }}" >> $GITHUB_ENV echo "DEPLOY_PATH=/demo-dev-www/wp-content/themes/my-theme" >> $GITHUB_ENV - name: Set outputs # Workaround to reference environment variables as inputs # using step outputs, since we can't pass environment # variables as inputs at the moment. id: sftp_details run: | echo "user=${SFTP_USER}" >> $GITHUB_OUTPUT echo "pass=${SFTP_PASS}" >> $GITHUB_OUTPUT echo "deploy_path=${DEPLOY_PATH}" >> $GITHUB_OUTPUT - name: Deploy via SFTP uses: pressidium/lftp-mirror-action@v1 with: host: ${{ secrets.SFTP_HOST }} port: ${{ secrets.SFTP_PORT }} user: ${{ steps.sftp_details.outputs.user }} pass: ${{ steps.sftp_details.outputs.pass }} remoteDir: ${{ steps.sftp_details.outputs.deploy_path }} options: '--verbose'

Вы также можете найти пример темы WordPress и рабочего процесса GitHub Actions в этом репозитории GitHub.

Вывод

Вот оно! GitHub Actions — это мощный инструмент, который упрощает автоматизацию создания и развертывания ваших тем и плагинов WordPress.

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

Взгляните на GitHub Marketplace, где — на момент написания — вы можете найти более 15 000 действий для использования в рабочих процессах GitHub Actions.

Так чего же ты ждешь?

• Взгляните на рабочий процесс этого репозитория на GitHub.
• Создайте новый файл YAML в папке .github/workflows/ в вашем репозитории Git.
• Наслаждайтесь автоматизированными сборками и развертываниями

Удачных развертываний!