Автоматизируйте свою рутину с помощью Github Actions
Все иногда зацикливаются на автоматизации, пытаясь сделать волшебную кнопку «Создать приложение», которая сделает всю работу за вас. В этой статье я попытаюсь немного приблизиться к этой мечте с помощью Github Actions.
Мы настроим следующий простой рабочий процесс:
- При нажатии на определенную ветку будут запущены действия git.
- Запустите тесты и убедитесь, что все они проходят
- Построить проект
- Отправлять файлы сборки на сервер с аутентификацией ssh
Я предполагаю, что у вас есть проект, хранящийся на github и сервере с аутентификацией ssh.
Прежде чем мы углубимся в кодирование, нам нужно установить некоторые секреты. В этом случае нам нужен только закрытый ключ ssh, чтобы мы могли получить доступ к нашему серверу из Github Actions. Чтобы не хранить его в жестком коде, мы будем хранить его в секретах нашего репозитория. Скопируйте свой закрытый ключ ssh, связанный с вашим сервером, и поместите его в секреты проекта следующим образом:
Далее нам нужно создать структуру папок .github/workflows в корневом каталоге проекта. Затем нам нужно создать наш первый файл рабочего процесса. demo.yml
.
Структура вашего проекта может выглядеть так
Давайте заполним наш файл demo.yml следующим содержимым:
name: GitHub Actions Demo
on:
push:
branches:
- master
jobs:
test:
runs-on: ubuntu-latest
strategy:
matrix:
node-version: [12.x]
steps:
- uses: actions/checkout@v2
- uses: actions/setup-node@v1
with:
node-version: ${{ matrix.node-version }}
- run: npm ci
- run: npm run test
build:
needs: [test]
runs-on: ubuntu-latest
strategy:
matrix:
node-version: [12.x]
steps:
- uses: actions/checkout@v2
- uses: actions/setup-node@v1
- run: set -eu
- run: mkdir "$HOME/.ssh"
- run: echo "${{ secrets.SSHKEY }}" > "$HOME/.ssh/id_rsa"
- run: chmod 600 "$HOME/.ssh/id_rsa"
# Build
- run: npm ci
- run: npm run build
# Deploy
- run: cd dist && rsync -e "ssh -i $HOME/.ssh/id_rsa -o StrictHostKeyChecking=no" --archive --compress --delete . username@ip:/path/to/place/build
Давайте построчно и посмотрим, что это такое!
Здесь мы указываем имя нашего рабочего процесса:
name: GitHub Actions Demo
Это ограничивает наш рабочий процесс запуском только тогда, когда мы нажимаем на основную ветку:
on:
push:
branches:
- master
Здесь много разных опций, вроде лимита на работу с пулл-реквестами, создание тегов и т. д. Вы можете прочитать список доступных действий здесь.
У нас всего 2 задачи: тестировать и строить.
«тестовая» работа
strategy.matrix
позволяет нам определять специальные переменные для наших заданий. В нашем случае нам нужно запустить «тестовое» задание, используя последнюю 12-ю версию узла:
strategy:
matrix:
node-version: [12.x]
Что такого особенного в матричных переменных? Они позволяют запускать несколько заданий для каждого значения в списке. Если вы хотите запустить свои тесты на нескольких версиях узла, вы можете сделать это следующим образом: node-version: [10.x, 12.x]
. И 2 задания будут выполняться для каждой версии.
В steps
мы определяем наши шаги для выполнения задания.
uses
ключевое слово говорит, что мы собираемся использовать некоторые внешние рабочие процессы, чтобы сделать некоторые вещи. В нашем случае есть 2 рабочих процесса: проверить наш проект, чтобы Github Actions мог получить к нему доступ, и настроить node.
steps:
- uses: actions/checkout@v2
- uses: actions/setup-node@v1
with:
node-version: ${{ matrix.node-version }}
Вы можете ознакомиться со всеми официальные действия, или вы даже можете создать свой собственный фрагмент и разместить его на github, чтобы каждый мог его использовать. Поехали, открытый исходный код!
Затем нам нужно установить наши зависимости и, наконец, запустить наши тесты из test
сценарий в package.json
. run
ключевое слово позволяет использовать команды, которые вы хотите выполнить.
- run: npm ci
- run: npm run test
npm ci
похож на npm install, за исключением того, что он предназначен для использования в автоматизированных средах, таких как тестовые платформы, непрерывная интеграция и развертывание, или в любой ситуации, когда вы хотите убедиться, что выполняете чистую установку своих зависимостей.
«строить» работу
Первые шаги почти такие же, за исключением needs: [test]
часть. Эта строка сообщает, что нам нужно дождаться прохождения задания «тест» и только после этого запустить задание «сборка». Если тесты не пройдены, сборка не запустится. Отлично, это именно то, что мы хотим!
Далее нам нужно установить наш ключ ssh в папку .ssh. Мы берем этот ключ из secrets
переменная, которая содержит все наши секреты, которые мы установили парой шагов ранее.
- run: set -eu
- run: mkdir "$HOME/.ssh"
- run: echo "${{ secrets.SSHKEY }}" > "$HOME/.ssh/id_rsa"
- run: chmod 600 "$HOME/.ssh/id_rsa"
Самый последний шаг — построить наш проект и, используя rsync команду, переносим нашу папку dist на сервер. Кроме того, нам нужно передать наш ключ ssh для успешной аутентификации.
Не забудьте изменить username@ip:/path/to/place/build на фактические значения
Важное примечание: этот подход может не сработать, если на вашем сервере есть стена с парольной фразой.
# Build
- run: npm ci
- run: npm run build
# Deploy
- run: cd dist && rsync -e "ssh -i $HOME/.ssh/id_rsa -o StrictHostKeyChecking=no" --archive --compress --delete . username@ip:/path/to/place/build
И вуаля! Мы настроили все, что нужно. Теперь каждый раз, когда мы нажимаем на мастер, наши действия Github будут запускать тесты и развертывать наш проект!
Вот 2 примера: с проваленными тестами (процесс сборки даже не начался!) и с пройденными тестами.
Это все!