Автоматизация задач GitHub — точка входа в цикл разработки

Задачи GitHub — самый любимый триггер для пресета SDLC движка процессов Forge . Остальные процессы (ресёрч, контент, поддержка, операции) входят в движок через API процессов, триггеры по расписанию или внешние webhook.

Как это идёт

flowchart TD
    I([issue.opened
метка: forge-pipeline]) --> WH[Обработчик webhook в кондукторе]
    WH --> IR[Запись задачи
sessionId · pipelineCloudSessionId · роль: PM]
    WH --> BR[Создана ветка
forge/pipeline/<номер-задачи>]
    WH --> T0[Первый ход поставлен в очередь]
    T0 --> AR[Агент работает]
    AR --> RF[ReleaseFinaliser]
    RF -->|извлечь передачу| NX[Поставить следующую роль]
    RF -->|группы охвата| DS[Создать нижестоящие задачи]
    NX --> RVA[Ревьюер подтверждает]
    RVA --> PR([PR открыт])

Как только конвейер запущен, через тот же обработчик проходят три вещи:

1. issue_comment — комментарий к исходной задаче. Превращается в ход одной роли для активного агента.
2. pull_request_review_comment — комментарий ревью к созданному PR. Вплетается в ту же сессию.
3. issues.labeled — смена меток может приостановить, возобновить или перезапустить конвейер.

Что сохраняется

У каждой задачи, которую ведёт Forge, есть своя запись:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

Issue:
  number:                  142
  title:                   "Add device-flow login to forge-cli"
  body:                    "..."
  repoOwner:               "simple-container-com"
  repoName:                "forge"
  role:                    "pm"          # начальная роль
  status:                  "in_progress"
  sessionId:               "ses_01HXXX..."
  pipelineCloudSessionId:  "csid_..."    # для отладки эксплуатации
  pipelineLastSnapshotId:  "snap_..."    # последний ход конвейера

Это даёт оператору одну запись для разбора, когда что-то выглядит не так: sessionId разворачивается в полный журнал сообщений, идентификатор облачной сессии — это взгляд воркера, а идентификатор снимка — точная точка ветвления, если нужно ответвиться оттуда.

Маршрутизация комментариев подробно

Когда кто-то комментирует активную задачу конвейера, кондуктор:

1. Проверяет подпись webhook секретом GitHub App организации.
2. Находит запись задачи по (repoOwner, repoName, number).
3. Разрешает sessionId и определяет текущую активную роль из состояния конвейера.
4. Добавляет текст комментария сообщением пользователя в эту сессию.
5. Ставит в очередь ход одной роли (без цепочки передач — это уточнение, а не передача следующему агенту).
6. Ставит реакцию 📥 на GitHub, чтобы автор комментария знал, что сообщение дошло.

Та же логика работает для комментариев ревью к PR — они вплетаются в сессию ревьюера, поэтому переписка по ревью остаётся продолжением существующего диалога.

Обращение с токенами

Запись в репозиторий идёт через токены установки GitHub App — они определяются по владельцу и выпускаются заново на каждую отправку. Поэтому коммиты передач, ветки и автоматические PR появляются от имени приложения Forge, а не от личного токена одного человека.

Токены приложения короткоживущие, около часа, а отдельный ход агента иногда идёт дольше. И клонирование, и отправка распознают истёкший токен, выпускают новый прямо посреди прогона и повторяют операцию — так длинный ход не теряет работу на последнем шаге. Персональный токен остаётся настроенным как запасной вариант на каждый вызов: нехватка прав у приложения деградирует один вызов, а не ломает конвейер.

Что вы получаете

Всё перечисленное уже работает в продакшене.

• Webhook issues с проверкой HMAC
• Маршрутизация issue_comment активной роли
• Вплетение pull_request_review_comment
• Аудиторский след со снимком на каждый ход
• Связка задача ↔ сессия
• Привязка токена приложения с обновлением прямо во время прогона

Попробовать

1. Установите GitHub App Forge на свой репозиторий.
2. Заведите задачу с описанием того, что нужно.
3. Поставьте метку forge-pipeline.
4. Следите за страницей задачи — каждый агент пишет комментарий о старте.
5. Комментируйте задачу, если нужно уточнить или перенаправить по ходу.
6. PR появится в том же репозитории, когда ревьюер подтвердит.