GitHub CI Checks Fix Trigger

Автоматически активируйте агентов для исправления ошибок CI проверок в pull request'ах.

Функция GitHub CI Checks Fix Trigger позволяет автоматически назначить агента-«реставратора» pull request'у, когда его CI проверки не пройдены. Агент анализирует логи ошибок и пытается исправить проблемы (например, падающие тесты, ошибки линтера, ошибки типов) следующим коммитом.

Как это работает

Общий процесс

PR открыт → агент создал или обновил PR
CI проверки запущены → GitHub Actions, CircleCI или другой CI запускает тесты
Проверка не пройдена → (линт, тесты, проверка безопасности и т.д.)
Триггер срабатывает → AACWorkflow обнаруживает ошибку
Назначен реставратор → агент-«реставратор» автоматически назначен для исправления ошибок
Агент анализирует → читает логи ошибок и сообщения об ошибках
Агент реализует исправление → коммитит изменения в ветку PR
CI перезапускается → проверки снова запускаются на новом коммите
Успех или эскалация → если проверки пройдены, PR готов к слиянию; если всё ещё не пройдено, эскалировать на человека

Политики одобрения

Вы контролируете какие ошибки CI активируют автоисправления:

Все ошибки — любая ошибка активирует реставратора
Конкретные проверки — только определённые проверки (например, «тесты» но не «безопасность»)
Только доверенные проверки — только известные исправляемые проверки (например, линтирование, форматирование)

Опасные проверки (безопасность, соответствие) можно настроить так, чтобы требовать одобрение человека перед попыткой автоисправления.

Настройка

Включите триггер исправления CI

Перейдите в Настройки → GitHub → CI Checks Policy.

Переключите Auto-fix CI check failures → ON
Выберите какие проверки автоисправляемые:
- ✓ Ошибки линтера (исправляемые через eslint --fix, gofmt, и т.д.)
- ✓ Ошибки типов (часто исправляемые через TypeScript inference)
- ✓ Форматирование (автоисправляемое через Prettier, форматировщики)
- ✗ Проверки безопасности (требует отзыва)
- ✗ Пользовательские workflow'и (часто требуют ручного вмешательства)
Выберите реставратора (или оставьте пусто для стандартного "code-fixer")
Установите максимум попыток повтора (по умолчанию: 2)
Нажмите Save

Назначьте агента-реставратора

По умолчанию AACWorkflow использует автоматически подготовленного агента "code-fixer". Для использования конкретного агента:

Перейдите в Настройки → GitHub → CI Checks Policy
Dropdown Fixer agent → выберите агента (например, "Frontend Fixer", "Backend Fixer")
Сохраните

Выбранный агент должен:

Иметь доступ на запись к репо (через GitHub token)
Знать как исправлять типы ошибок, которые проверяют ваши CI проверки
Быть доступным (не перегруженным другими задачами)

Как работает реставратор

Шаг 1: Обнаружение ошибки

Когда проверка PR не пройдена, AACWorkflow читает логи ошибок из GitHub (через GitHub API):

{
  "check_run": "tests",
  "conclusion": "failure",
  "title": "Run tests",
  "output": {
    "title": "2 test failures",
    "summary": "packages/views/components/button.test.tsx:42 - expect....",
    "annotations": [
      {
        "path": "packages/views/components/button.test.tsx",
        "start_line": 42,
        "message": "Timeout: test 'renders with onClick handler' did not complete"
      }
    ]
  }
}

Шаг 2: Анализ и планирование

Агент-реставратор:

Клонирует ветку PR локально
Читает логи ошибок и аннотации ошибок
Классифицирует ошибки:
- Исправляемые: синтаксические ошибки, нарушения линтера, отсутствующие типы, timeout'ы тестов
- Эскалировать: ошибки доступа, сбои инфраструктуры, проблемы логики теста
Планирует исправление (например, «Добавить await к async тесту», «Удалить неиспользуемую переменную»)

Шаг 3: Реализация исправления

Реставратор коммитит изменения в ветку PR:

git checkout feature/aac-42-oauth
# Исправить ошибки (синтаксис, типы, линт, тесты)
git add .
git commit -m "fix: resolve CI check failures

- packages/views/components/button.test.tsx:42 - add await for async test
- server/cmd/server/main.go:18 - gofmt formatting
"
git push

GitHub автоматически активирует новый CI запуск (так как ветка обновлена).

Шаг 4: Повтор или эскалация

После коммита исправления:

CI пройдена ✅ → PR теперь готов к слиянию (требуется отзыв человека)
CI не пройдена снова ❌ → если лимит max_retry_attempts не превышен, логика повтора активируется:
- Анализирует новую ошибку
- Планирует новое исправление
- Коммитит снова
Лимит повторов превышен → эскалировать на человека:
- Постить комментарий: "I've attempted 2 fixes but CI still fails. See details below."
- Оставить ветку PR в лучшем возможном состоянии
- Назначить человеку для отзыва

Примеры

Пример 1: Ошибка линтера (автоисправляемая)

Ошибка CI: ESLint сообщает о неиспользуемой переменной в apps/web/app/page.tsx:15

Действие реставратора:

Обнаруживает: unused variable 'tempUser'
Запускает: eslint --fix apps/web/app/page.tsx
Коммитит: fix: remove unused variable
Пушит
CI перезапускается и пройдена ✅

Результат: PR теперь зелёный; человек проверяет код.

Пример 2: Timeout теста (обычно исправляемо)

Ошибка CI: Тест timeout в packages/core/agents/agents.test.ts:120

Действие реставратора:

Читает ошибку: "Test 'should handle concurrent requests' did not complete"
Открывает файл, видит что await отсутствует на async операции
Добавляет await перед async вызовом
Коммитит: fix: add missing await in concurrent test
Пушит
CI перезапускается; тест завершается за 500ms ✅

Результат: PR зелёный.

Пример 3: Ошибка типов (варьируется в исправляемости)

Ошибка CI: TypeScript сообщает об ошибке типа в packages/core/api/client.ts:45

Действие реставратора:

Читает: Type 'undefined' is not assignable to type 'string'
Проверяет контекст; не может определить правильное значение
Пытается: Добавить guard типа (например, ?? '')
Коммитит и пушит
CI перезапускается; проверка типов проходит ✅

Результат: PR зелёный (но человек должен проверить guard типа для уверенности).

Пример 4: Проверка безопасности (эскалирует)

Ошибка CI: Snyk обнаруживает уязвимую зависимость в package.json

Действие реставратора:

Читает вывод Snyk: "lodash < 4.17.21 is vulnerable"
Проверяет безопасно ли обновление: npm update lodash
Тестирует: npm test — все проходят ✅
НО: Проверки безопасности имеют require_approval: true
Постит комментарий: "Found vulnerable dependency; attempting upgrade."
Ждёт одобрения человека перед пушем исправления

Результат: Эскалировано на человека; реставратор ждёт OK для коммита.

Одобрение и безопасность

Уровни доверия

Настройте уровни доверия по типу проверки:

Проверка	Уровень доверия	Поведение
Линтер (ESLint, gofmt)	Высокий	Автоисправление без одобрения
Проверка типов (TypeScript)	Высокий	Автоисправление без одобрения
Форматирование (Prettier)	Высокий	Автоисправление без одобрения
Тесты	Средний	Автоисправление, но эскалировать если > 2 ошибок
Безопасность (Snyk, OWASP)	Низкий	Требует одобрение перед исправлением
Пользовательские workflow'и	Низкий	Требует одобрение перед попыткой исправления

Максимум попыток повтора

Установите сколько раз реставратор должен повторить перед эскалацией:

1 — одна попытка; эскалировать при любой ошибке
2 (по умолчанию) — две попытки; эскалировать после второй ошибки
3 — три попытки; большинство ошибок исправляются к третьей попытке

API и автоматизация

Активируйте исправление вручную

Если автоисправление отключено, вы можете активировать его вручную:

POST /api/workspaces/{ws}/github/pr/{pr_number}/trigger-fix

Body:

{
  "check_run_id": 12345,
  "agent_id": "550e8400-e29b-41d4-a716-446655440000"
}

Отключите исправление для конкретного PR

Если вы хотите отключить автоисправление для одного PR (например, для ручного расследования):

PATCH /api/workspaces/{ws}/github/pr/{pr_number}

Body:

{
  "auto_fix_ci_enabled": false
}

Переобновите:

{
  "auto_fix_ci_enabled": true
}

Запросите историю попыток исправления

GET /api/workspaces/{ws}/github/pr/{pr_number}/fix-history

Возвращает:

{
  "pr_number": 123,
  "fix_attempts": [
    {
      "attempt": 1,
      "triggered_at": "2025-06-22T15:30:00Z",
      "check_run": "tests",
      "failure_summary": "2 tests failed (timeouts)",
      "agent_id": "550e8400-e29b-41d4-a716-446655440000",
      "fix_commit": "abc123def456",
      "result": "success"
    },
    {
      "attempt": 2,
      "triggered_at": "2025-06-22T15:35:00Z",
      "check_run": "lint",
      "failure_summary": "3 ESLint violations",
      "agent_id": "550e8400-e29b-41d4-a716-446655440000",
      "fix_commit": "def456abc123",
      "result": "escalated"
    }
  ]
}

Лучшие практики

Начните с высокодоверенных проверок — линтер и форматирование самые безопасные для автоисправления
Проверьте первые несколько автоисправлений — убедитесь в суждениях реставратора перед полным доверием
Используйте выделенных агентов-реставраторов — агентов обученных анализу ошибок и восстановлению
Следите за эскалациями — если реставратор часто эскалирует, это может быть из-за неясных ошибок CI; улучшите логи
Установите разумные лимиты повторов — обычно 2-3 попытки ловят исправляемые ошибки

Устранение проблем

"Реставратор делает неправильные исправления"

Проверьте инструкции агента-реставратора (Настройки → Агенты)
Проверьте прошлые попытки исправления для выявления паттернов
Добавьте более специфичный контекст в логи CI проверок (лучшие сообщения об ошибках помогают)
Рассмотрите использование другого агента-реставратора или добавьте gate одобрения

"Реставратор постоянно эскалирует вместо исправления"

Ошибки проверок могут быть неисправляемыми (например, безопасность, инфраструктура)
Агент-реставратор может не иметь контекста; проверьте его инструкции и возможности
Увеличьте max_retry_attempts если он слишком низкий
Добавьте примеры в системный промпт агента для руководства принятием решений

"Нужно ручное исправление но автоисправление запустилось первым"

Перейдите в PR на GitHub
Установите auto_fix_ci_enabled: false (через API или Настройки)
Расследуйте и вручную исправьте основную ошибку
Переобновите автоисправление когда ошибка ясна

Связанные функции

GitHub интеграция — см. GitHub integration
GitHub PR создание — см. GitHub PR Creation Flow
Политики одобрения — см. Approval Policies

Содержание