Автоматизация аналитических процессов с помощью GitHub Actions: практический гайд

Привет, Хабр! Хочу поделиться своей историей того, как я пришла к GitHub Actions в попытках автоматизировать сбор аналитики для личного использования.

Статья будет полезна аналитикам, которые хотят автоматизировать сбор и анализ данных для своих небольших пет‑проектов. Важное слово тут — небольшие, так как у этого способа автоматизации есть конкретные ограничения по суммарному времени отработки скрипта в месяц 🙂

---

Почему я искала автоматизацию

Возвращаясь в самое начало — у меня была задача: парсить данные и отправлять готовый мини‑отчёт в Telegram‑чат. Сама задача довольно простая, поэтому разбирать в статье скрипты для парсинга и анализа данных я не буду. Основной фокус — на способе автоматизации. При планировании я руководствовалась тремя принципами:

• Не тратить деньги. Никаких платных сервисов и аренды серверов.

• Не запускать вручную. Скрипты должны работать сами по расписанию.

• Простота создания. Без сложной инфраструктуры и администрирования.

Первый вариант — cron

Первое, что приходит на ум — запуск на локальной машине, как пример — классический cron на Linux. Способ рабочий, но есть существенное ограничение: система должна быть включена. Если отчёт нужен каждый день в 7 утра, то и ноут должен быть включён в это время. Это сразу нарушает второй принцип

Варианты с сервером или облаком

Следующий вариант — поднять сервер или арендовать его. Но для небольшого проекта это слишком: нет желания тратить деньги, а ещё нужно время на настройку. Аналитики обычно не админы, и в такие дебри углубляться не хочется. Да, можно было бы использовать Google Cloud Scheduler, но все файлы у меня уже хранятся в гите, поэтому вариант с использованием нескольких сервисов для проекта выглядит не оптимальным.

Финальный вариант — GitHub Actions

Думаю, что мой выбор сервиса для проекта уже стал очевиден. Я нашла наводку на GitHub Actions во время реализации. Сам github использовала уже давно, но этот функционал ранее использовать не доводилось. Существенных отличий от аналога выше, на самом деле, я не заметила. В моем случае удобно использовать именно actions, так как все репозитории храню в гите. Собственно, actions позволяет запускать скрипты:

• По расписанию (cron).

• По событию (push, pull request, создание релиза и т. д.).

• Вручную.

Для аналитика это возможность настроить:

• ежедневный парсинг данных и сохранение их в репозиторий;

• запуск скриптов для анализа;

• отправку отчётов в Telegram или любую другую систему;

• мелкие задачи для автоматизации своей работы.

Ограничения бесплатного тарифа

Сразу отмечу, что я использовала только free-тариф, так как оплаты противоречат первому требованию проекта. В бесплатный тариф GitHub Free входит ограничение на время и хранилище для приватных репозиториев: 2 000 минут выполнения в месяц и 500 МБ для артефактов (файлы, которые получаются в результате выполнения workflow: логи, csv-файлы и т.п). Для небольших задач этого более чем достаточно. В моём примере за 20 дней было израсходовано всего 133 минуты.

---

Архитектура: как это работает

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

TEST_REPO_FOR_HABR │ ├── .github │   └── workflows │       └── run_daily.yml │ ├── .gitignore ├── requirements.txt ├── parser.py ├── delete_old_data.py ├── parsed_data.csv └── README.md

Пишем скрипт для парсинга/ любой другой цели

В моем примере выше лежит два скрипта на python:

1. parser.py для парсинга и отправки данных в тг. Он же создает и обновляет parsed_data.csv

2. delete_old_data.py для удаления старых данных старше 3-х месяцев

Создаем репозиторий на GitHub

1. Делаем его приватным, если хотим скрыть данные.

2. Добавляем директорию .github/workflows/ — здесь будут храниться YAML‑файлы c описанием workflow.

3. Внутри папки создаем YAML‑файл, где определяем:

   • расписание запуска (cron);

   • виртуальную среду (Linux, Windows, macOS);

   • последовательность шагов (установка зависимостей, запуск скриптов, коммит файлов и т. п.)

4. Добавляем в репозиторий py и csv скрипты, которые указаны в yml-файле.

Пример yml-файла

Ниже показан упрощённый workflow daily.yml, который каждый день в 07:00 UTM запускает скрипт для парсинга, фиксирует изменения в CSV и удаляет устаревшие данные:

# Придумываем название name: Daily bot  # Устанавливаем расписание on:   schedule:     - cron: '0 7 * * *'  # Возможные дополнения для запуска по push: push:   branches:     - main  # Глобальные переменные окружения (подтягиваются из Secrets) env:   BOT_TOKEN: ${{ secrets.tg_token }}   CHANNEL_ID: ${{ secrets.channel }}  jobs:   daily-run:     runs-on: ubuntu-latest  # GitHub-hosted runner      steps:        # 1. Выгружаем код репозитория       - name: Checkout Code         uses: actions/checkout@v4        # 2. Устанавливаем зависимости       - name: Install dependencies         run: python -m pip install -r requirements.txt        # 3. Запускаем парсер       - name: Run parser         run: python parser.py        # 4. Коммитим CSV, если он изменился (используем встроенный токен для пушей)       - name: Commit CSV if changed         env:           GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}          run: |           git config user.name "github-actions[bot]"           git config user.email "github-actions[bot]@users.noreply.github.com"           git add parsed_data.csv           git diff --cached --quiet || git commit -m "Update CSV with latest data"           git push               # 5. Запускаем скрипт для удаления старых данных       - name: Delete old data         run: python deleting_old_data.py

Ключевые моменты:

• Cron принимает расписание в формате UTC. Если вы в другом часовом поясе, учитывайте смещение.

• Секреты (tg_token, channel) хранятся в разделе Settings → Secrets and variables → Actions (про это поговорим ниже);

• Встроенный токен GITHUB_TOKEN позволяет коммитить и пушить изменения без дополнительных настроек.

• При необходимости можно добавить дополнительные шаги — например, очистку временных файлов или отправку уведомлений.

Работа с Secrets

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

1. Открываем настройки репозитория: Settings → Secrets and variables → Actions.

2. Нажимаем New repository secret, задаём имя (например, TELEGRAM_TOKEN) и значение.

3. В workflow обращаемся к нему как ${{ secrets.TELEGRAM_TOKEN }}.

После создания секретов мы сможем их увидеть в настройках, но просмотреть, что написано внутри — уже никак 🙂

В Python получаем переменные через os.getenv (через функцию, которая позволяет получать переменные окружения). Ниже пример блока с отправкой сообщения в телеграм-чат.

import os, requests from dotenv import load_dotenv load_dotenv()  # Предшествующий блок с парсингом и анализом, который не рассматриваем metrics_text = "Рандомный текст для чата"  bot_token = os.getenv('BOT_TOKEN') channel_id = os.getenv('CHANNEL_ID')  send_text_url = f'https://api.telegram.org/bot{bot_token}/sendMessage'  payload = {     'chat_id': channel_id,     'text': metrics_text,     'parse_mode': 'HTML' }  requests.post(send_text_url, data=payload)

Таким образом можно скрыть все конфиденциальные данные от чужих глаз.

Технические моменты

Не забываем про то, что наш репозиторий содержит .gitignore и requirements.txt.

Чтобы GitHub Actions (и любой другой разработчик) понимал, какие пакеты нужно установить для работы скрипта, принято хранить список зависимостей в файле requirements.txt. Это гарантирует, что при каждом запуске GitHub Actions будут установлены именно те версии библиотек, которые нужны проекту.

Requirements мы устанавливаем через yml-файл в этом блоке:

- name: Install dependencies   run: python -m pip install -r requirements.txt

А сам файл можно создать в терминале следующим образом:

pip freeze > requirements.txt

И, возвращаемся к .gitignore — он определяет файлы, которые игнорируются при обновлении репозитория. Это могут быть временные CSV и кэшированные файлы.

В нашем случае .gitignore включает в себя только три типа данных:

.env .csv .yml

Собственно, это вся настройка автоматизации по нашей задаче. Скрипты будут выполняться по расписанию, указанному в yml-файле. Вcе ошибки и проблемы можно просматривать через вкладку Actions → Jobs. Для отладки всегда можно добавить логирование или отслеживать ключевые моменты через print → так ошибки можно просмотреть через actions.

---

Полезные советы

• Начинайте с самого простого: запустите workflow с одним шагом по cron, чтобы убедиться, что всё работает.

• Все токены и ключи храните только в Secrets.

• Сначала отрабатывайте скрипты локально или в интерактивной среде, чтобы не тратить лимит минут на поиск ошибок.

• Добавь логирование ошибок, если хочешь их отслеживать или выводи через print, если хочешь смотреть их через actions.

• Если в проекте несколько задач, используйте разные jobs или workflows — это позволит параллелить выполнение и не смешивать логику.

• Следите за потреблением минут: использование macOS‑runner’ов расходует больше минут, чем Linux.

Итоги

Для меня GitHub Actions оказался отличным вариантом для небольших аналитических задач. Я бы спокойно рекомендовала его аналитикам-джунам для создания своих пет-проектов.

Еще больше полезных материалов в моем TG-канале. Подписывайтесь и читайте контент по ссылке.