Перейти к содержанию

Пайплайн для деплоя mkdocs средствами gitea

Такс, как и обещал притаранил тебе рабочий пайплайн для авто деплоя mkdocs через gitea.

Чтобы всё это заработало, в проекте тебе нужно создать структуру:

.gitea/workflows/deploy.yml

Файл можешь обозвать как угодно.

name: Build and Deploy Bashdays Blog

on:
  push:
    branches:
      - main

jobs:
  build:
    runs-on: super-runner
    container:
        image: catthehacker/ubuntu:act-22.04

    steps:
      - name: Checkout repository
        uses: actions/checkout@v3

      - name: Install dependencies and build
        run: |
          pip install -r requirements.txt
          mkdocs build

      - name: Deploy to Server
        uses: https://gitea.com/aquelle1/ssh-deploy@main
        env:
          SSH_PRIVATE_KEY: ${{ secrets.SSH_PRIVATE_KEY }}
          ARGS: "-rlgoDzvc -i --delete" 
          SOURCE: "site/"
          REMOTE_HOST: ${{ secrets.REMOTE_HOST }}
          REMOTE_USER: ${{ secrets.REMOTE_USER }}
          TARGET: ${{ secrets.REMOTE_TARGET }}

Разбор полётов

Давай кратенько пробежимся:

Триггер on: push: запускается если что-то запушено в ветку main.

Почему в main а не в master? Читай тут.

Следом запускается джоба build на раннере super-runner, не забываем зарегать себе раннер, без него нихуя не получится.

Что такое раннеры и как с ними работать, можешь загуглить, там по сути ничего сложного. Поэтому этот этап пропущу. Чуть позже отдельным постом запилю про это.

Дальше используем адаптированный контейнер с убунтой 22.04 специально адаптированный под тестирование GitHub Actions через act.

Почему GitHub Actions? Потому что gitea унаследовало синтаксис и пайплайны в теории могут переносится между системами.

Пиздеть не буду, не переносил, но если у тебя есть опыт, то было бы интересно увидеть его в комментариях.

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

После сборки идет секция с деплоем, я использую этот экшен. Основан он на rsync поверх ssh.

Забиваем нужные ключи и переменные, которые требуются для работы этого экшена. Переменные определяешь в настройках проекта в gitea в секции secrets.

Описание переменных

SSH_PRIVATE_KEY = Приватный ssh ключ с которым раннер пойдет на твой сервер и подключиться по ssh к нему. Соответственно публичная часть ключа должна быть прописана у пользователя на сервере в файле ~/.ssh/authorized_keys.

Как работать с ssh ключами, читай в канале по тегу #linuxfactory

ARGS = Аргументы для rsync, рекурсивное копирование, сохранение прав доступа, удаление файлов которые не в локальной версии.

SOURCE = Какой каталог со статикой отправляем. В Mkdocs статика генерится по умолчанию в папку site.

REMOTE_HOST & REMOTE_USER = Айпишник или домен продакшена на который деплоим + имя пользователя под которым подключаемся к серверу.

TARGET = В какую папку на проде скинуть содержимое папки site.

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

Заключение и выводы

Вот и всё. Теперь при пуше в main ветку, автоматически запустится пайплайн и на прод выкатятся изменения.

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

Хорошего тебе вечера, теперь уже до завтра!

ㅤЧитать первым в Телеграм

Комментарии