4 паттерна GitHub Actions для Monorepo ETL
Запуск трех сайтов из одного монорепозитория создает проблемы. Вы сталкиваетесь с тремя отдельными ETL-задачами, тремя пересборками контента и тремя конвейерами развертывания. Если их не координировать, они будут конфликтовать.
Я потратил шесть недель на тестирование расписаний, чтобы стабилизировать эту конфигурацию. Вот четыре паттерна, которые я использую.
- Используйте временные смещения для Cron-задач
Запуск всех ETL-задач одновременно приводит к сбоям. Задачи конкурируют за лимиты API (rate limits). Когда HuggingFace или GitHub возвращают ошибку 429, выполнение прерывается.
Чтобы предотвратить это, я использую 30-минутные смещения.
- Задача первая запускается в 02:00
- Задача вторая запускается в 02:30
- Задача третья запускается в 03:00
Тридцати минут достаточно, чтобы завершить тяжелую выгрузку до начала следующей задачи. Это позволяет держать логи чистыми и предотвращает конфликты API.
- Используйте флаги пропуска (skip flags), чтобы остановить ненужные пересборки
Каждая ETL-задача заканчивается развертыванием в Vercel. Проблема возникает, когда коммиты со статьями также запускают пересборки. Без четкого плана каждое обновление статьи заставляет пересобираться все три сайта. Это тратит минуты сборки.
Я использую тег [skip publish-articles] в сообщениях коммитов ETL.
Я добавил шаг в свой workflow, который проверяет наличие этого флага. Если тег найден, workflow пропускает шаг сборки и развертывания. Это позволяет разделить ETL-конвейеры и конвейеры для статей.
- Используйте фильтры путей для таргетинга конкретных сайтов
Вы не хотите, чтобы обновление одного сайта запускало три развертывания. Я настраиваю workflow каждого сайта так, чтобы он отслеживал только свою папку и папку с общими пакетами (shared packages).
Пример логики:
- Сайт с AI-инструментами отслеживает только apps/ai-tools/
- Сайт с OSS-альтернативами отслеживает только apps/oss-alternatives/
Если вы измените код в общей директории, все сайты будут пересобраны. Я принимаю этот компромисс, так как изменения в общем коде случаются редко.
- Добавьте ручной запуск (manual dispatch) для контроля
Cron берет на себя повседневную рутину. Manual dispatch берет на себя все остальное. Я использую workflow_dispatch, чтобы иметь возможность:
- Перезапустить упавшую ETL-задачу
- Принудительно обновить данные после их добавления
- Запустить тестовый прогон (dry run), чтобы проверить данные без записи в базу данных
Интерфейс GitHub отображает выпадающее меню для этих действий. Это предотвращает опечатки и упрощает отладку.
Резюме
Эти паттерны не сложны. Они явны. Я храню простой markdown-файл в своем репозитории, чтобы документировать эти правила. Это гарантирует, что я не сломаю систему при добавлении новых workflow.