CI триаж агент

Когда ваш GitHub Actions pipeline выходит из строя, поиск корневой причины часто требует чтения логов, понимания контекста и принятия решения. AI-powered CI триаж агент может автоматизировать это 24/7.

Что делает агент

CI триаж агент непрерывно мониторит ваши CI запуски и, когда сборка выходит из строя:

1. Читает CI логи — получает логи GitHub Actions и парсит вывод ошибок
2. Анализирует контекст — просматривает последние коммиты, PR'ы и изменения кода
3. Генерирует резюме — пишет краткий анализ корневой причины с фрагментами кода
4. Предлагает исправление — предлагает конкретное изменение или шаг отладки
5. Принимает меры — создаёт GitHub задачу, открывает черновик PR или комментирует оригинальный PR
6. Отслеживает разрешение — обновляет задачу со статусом исправления при слиянии PR'ов

Настройка

Предварительные условия

• Рабочее пространство AACWorkflow с активным агентом (см. Быстрый старт)
• Интеграция с GitHub включена (Параметры → Интеграции)
• Агент имеет доступ к GitHub API (repo, actions scope)

Шаг 1: Создайте CI триаж агент

1. Перейдите в Параметры → Агенты и нажмите Новый агент
2. Выберите ваш рантайм и провайдера (Claude Code, Codex или аналогичный)
3. Назовите его ci-triage или build-doctor
4. Откройте его конфиг и добавьте навык или кастомное приглашение:

Роль: CI исследователь ошибок
Задача: Когда GitHub Actions работа выходит из строя:
1. Получите лог сборки из GitHub API
2. Распарсите сообщения об ошибках и stack trace'и
3. Проверьте git diff неудачного коммита
4. Суммируйте корневую причину в 2-3 пункта
5. Предложите однострочное исправление или команду отладки
6. Создайте GitHub задачу с меткой "ci-failure"
7. Свяжите задачу с исходящим PR

Контекст: Будьте лаконичны. Сосредоточьтесь на том, что сломалось, а не на том, что сработало.

Шаг 2: Подключите триггер

Добавьте GitHub Actions workflow .github/workflows/notify-ci-triage.yml:

name: Notify CI Triage Agent

on:
  workflow_run:
    workflows: ["Build", "Test"]
    types: [completed]

jobs:
  notify:
    if: failure()
    runs-on: ubuntu-latest
    steps:
      - name: Trigger CI triage agent
        run: |
          curl -X POST https://aacworkflow.com/api/webhooks/ci-failed \
            -H "Authorization: Bearer ${{ secrets.AACWORKFLOW_TOKEN }}" \
            -H "Content-Type: application/json" \
            -d '{
              "workflow_run_id": "${{ github.run_id }}",
              "repository": "${{ github.repository }}",
              "branch": "${{ github.ref }}"
            }'

Замените webhook URL на конечную точку вашего экземпляра AACWorkflow (или используйте интеграцию Zapier/Make как альтернативу).

Шаг 3: Назначьте задачу

Назначьте GitHub задачу агенту ci-triage с меткой ci-failure. Агент пробуждается и исследует.

Примеры вывода

Ввод: GitHub Actions работа выходит из строя с «connection timeout» во время теста миграции базы данных.

Резюме агента:

Корневая причина: Timeout скрипта миграции. Пул тестирования имеет только 2 соединения; параллельные миграции исчерпывают пул.

Исправление: Увеличьте DB_POOL_SIZE=5 в окружении тестирования.

PR создан в черновике: #1437 с исправлением. Повторный запуск теста запрошен.

Предпринятые действия: Создаёт задачу #1436 "CI: DB pool exhaustion on migration tests", открывает PR #1437 как черновик, комментирует оригинальный PR с резюме.

Советы и лучшие практики

• Паттерны меток — помечайте CI ошибки с согласованными метками (ci-failure, ci-blocking, ci-flaky), чтобы вы могли фильтровать и расставлять приоритеты
• Интеграция Slack — направьте находки агента в Slack канал для видимости по команде
• Повторить при исправлении — как только исправление слито, попросите агента повторно запустить CI работу, чтобы подтвердить, что она проходит
• Обнаружение нестабильного теста — если тест проходит при повторном запуске, отметьте его как нестабильный и создайте отдельную задачу расследования

Связанные руководства

• Dependency Update Agent — аналогичная автоматизация для обновлений безопасности
• Release Notes Agent — отслеживайте что изменилось и почему