Интеграция Baserow и GitHub через вебхуки и REST API

Открытая редакция Baserow связывается с GitHub в обе стороны без платных шлюзов: вебхуки GitHub обновляют строки Baserow при коммитах, слияниях pull request’ов и закрытии issue, а автоматизация Baserow отправляет HTTP-запросы, которые запускают workflow GitHub Actions по паттерну repository dispatch - ниже разобраны типичные сценарии, архитектура связки и настройка обоих направлений.

Обзор

Разработка идёт в GitHub: коммиты, pull request’ы, ветки. Бизнес-контекст - роадмапы, приоритеты, согласования - удобнее вести в Baserow. Интеграция закрывает разрыв между двумя системами: паттерн repository dispatch отправляет сигналы из Baserow в GitHub, а вебхуки GitHub обновляют записи Baserow в ответ на события репозитория.

Сценарии использования

• Синхронизация роадмапа: issue GitHub зеркалируются в записи функций в таблице Baserow.
• Триаж багов: баги, заведённые в Baserow, попадают в бэклог разработчиков как issue GitHub.
• Журнал релизов: changelog формируется в Baserow автоматически при публикации релиза.
• Онбординг участников: приглашение в организацию GitHub создаётся по записи в Baserow.
• Подготовка окружений: инфраструктура разворачивается по факту согласования в Baserow.

Архитектура: паттерн repository dispatch

Связка построена на цикле из четырёх шагов:

1. Сигнал - автоматизация Baserow отправляет dispatch-событие с метаданными полезной нагрузки (идентификатор строки, тип действия).
2. Приём - GitHub получает и аутентифицирует запрос.
3. Выполнение - workflow GitHub Actions выполняет саму задачу.
4. Обратная связь - результат обновляет исходную строку Baserow.

Технические требования

• Personal Access Token GitHub с областью repo.
• Database-токен (API-токен) Baserow с правами на запись.
• Автоматизация Baserow, настроенная на отправку HTTP POST-запросов через REST API базы данных .
• Файл workflow GitHub Actions (.github/workflows/baserow_handler.yml), который принимает dispatch-событие и выполняет задачу.

Обратное направление: вебхуки GitHub

Вебхуки GitHub закрывают противоположный сценарий: Baserow пассивно слушает события репозитория и обновляет строки, когда разработчики коммитят код, сливают pull request или закрывают issue. Настройка идёт через тот же механизм вебхуков Baserow , что используется для остальных интеграций - подходит для сценариев, управляемых статусом, а не действием.

Привязка записей по идентификатору

Храните перекрёстные ссылки между системами: номер строки Baserow - в issue GitHub, номер issue GitHub - в поле Baserow. Это гарантирует точное сопоставление записей даже при большом объёме данных и исключает ситуации, когда одна и та же задача случайно задваивается в обеих системах.

Часто задаваемые вопросы

Нужен ли токен с правами администратора репозитория? Нет - Personal Access Token GitHub с областью repo достаточен для чтения и записи issue, pull request и запуска workflow; более широкие права не требуются для описанных сценариев.

Можно ли обойтись только вебхуками, без dispatch-паттерна? Да, если нужен исключительно приём событий из GitHub в Baserow. Dispatch-паттерн нужен для обратного направления - когда Baserow должен инициировать действие в GitHub.

Что произойдёт, если workflow GitHub Actions завершится с ошибкой? Строка Baserow не получит обновление обратной связи, пока автоматизация или скрипт не отправят повторный запрос - логику повторных попыток стоит закладывать на стороне workflow.

Смежные темы - интеграция с GitLab для похожего паттерна с другой платформой репозиториев и интеграция с Vercel для связки Baserow с процессом деплоя.