Автоматизируйте свою рутину с помощью Github Actions

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

  • При нажатии на определенную ветку будут запущены действия git.
    • Запустите тесты и убедитесь, что все они проходят
    • Построить проект
    • Отправлять файлы сборки на сервер с аутентификацией ssh

Я предполагаю, что у вас есть проект, хранящийся на github и сервере с аутентификацией ssh.

Прежде чем мы углубимся в кодирование, нам нужно установить некоторые секреты. В этом случае нам нужен только закрытый ключ ssh, чтобы мы могли получить доступ к нашему серверу из Github Actions. Чтобы не хранить его в жестком коде, мы будем хранить его в секретах нашего репозитория. Скопируйте свой закрытый ключ ssh, связанный с вашим сервером, и поместите его в секреты проекта следующим образом:
Скриншот 12 февраля 2022 г., 02.43.14.png

Далее нам нужно создать структуру папок .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 примера: с проваленными тестами (процесс сборки даже не начался!) и с пройденными тестами.
Неудачные тесты
Все хорошо

Это все!

автоматизация шутка.jpeg

Похожие записи

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *