Как вывести результат AI-регрессионных тестов в GitHub Actions Job Summary

Нужен репозиторий GitHub, доступ к его Actions и возможность добавить файл в каталог .github/workflows. Подготовьте тестовую ветку и одно синтетическое обращение с известным ожидаемым результатом. Не берите production-заявки: даже если runner временный, ввод и диагностика оказываются в истории запуска. Для Python-части используйте unittest из стандартной библиотеки; если в вашем проекте есть дополнительные импорты, установите их отдельно из контролируемого файла зависимостей.

До коммита запишите контракт: какие поля обязательно должны быть в результате, какие значения разрешены и при каком несоответствии job получает ненулевой код выхода. Сначала выполните тот же скрипт локально. Это позволяет различить ошибку Python от ошибки описания workflow. Если проверка обращается к внешней модели, разделите транспортную ошибку, отсутствие ключа и несоответствие ответа: эти причины требуют разного исправления.

Пошаговая настройка

1. Создайте нужные каталоги и файлы из блоков ниже; имена путей в YAML должны совпадать с именами файлов в репозитории. Файл workflow хранится внутри .github/workflows, а тестовый код — в tests или scripts согласно примеру.
2. Проверьте три секции YAML: on задаёт событие, permissions ограничивает встроенный токен, jobs содержит runner и последовательность шагов. Не вставляйте ключи или закрытые тексты в YAML.
3. Создайте YAML и скрипт, затем измените вычисление actual так, чтобы оно вызывало ваш нормализатор. Переменную GITHUB_STEP_SUMMARY GitHub предоставляет шагу; Python добавляет Markdown в этот файл. Статус шага определяется ненулевым exit code, а не красивой таблицей: при mismatch скрипт обязан завершиться ошибкой. Откройте страницу запуска и блок Summary; проверьте, что видны две строки с именами фикстур. Не записывайте туда неочищенный текст клиента, ключи или прямую ссылку на закрытый ответ модели. При нескольких шагах их summary собираются на странице job, но файл каждого шага отдельный.
4. Сначала воспроизведите успешный вход, затем намеренно измените одно ожидаемое значение и убедитесь, что job падает. Проверка без негативного сценария не доказывает, что тест вообще способен обнаружить регрессию. После этого верните правильное значение и повторите запуск.
5. При сбое откройте конкретный job и шаг, а не ориентируйтесь только на общий статус workflow. Проверьте событие запуска, выбранную ветку, наличие файлов, код завершения скрипта и последние безопасные диагностические сообщения.

Готовый шаблон workflow

Скопируйте YAML; если в блоке указаны два имени файла, разделите его на два соответствующих файла. Ссылки на внешние actions и параметры проверены по их официальным README на 19.09.2026.

name: AI contract summary
on:
  pull_request:
permissions:
  contents: read
jobs:
  summary:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7
      - uses: actions/setup-python@v7
        with:
          python-version: '3.13'
      - name: Evaluate and write summary
        run: python scripts/summary_eval.py

Код или тестовая фикстура для копирования

Этот блок даёт исходную контрольную точку. Встраивая его в приложение, заменяйте демонстрационный нормализатор на собственный импорт, сохраняя контракт и синтетические тестовые входы.

# scripts/summary_eval.py
import os, pathlib
cases = [("urgent-payment", "Срочно: платеж не прошёл", "high"),
         ("ordinary-question", "Когда придёт чек?", "normal")]
rows, failures = [], []
for name, text, expected in cases:
    actual = "high" if text.startswith("Срочно:") else "normal"
    ok = actual == expected
    rows.append(f"| {name} | {expected} | {actual} | {'OK' if ok else 'FAIL'} |")
    if not ok: failures.append(name)
summary = "## Контракт маршрутизации

| Кейс | Ожидается | Факт | Статус |
|---|---|---|---|
" + "
".join(rows) + "
"
path = pathlib.Path(os.environ["GITHUB_STEP_SUMMARY"])
with path.open("a", encoding="utf-8") as f: f.write(summary)
if failures: raise SystemExit("Failed cases: " + ", ".join(failures))

Реалистичный вход и ожидаемый результат

Для кейса urgent-payment ожидается и получается high; для ordinary-question — normal. Сводка содержит обе строки OK. Если нормализатор ошибочно помечает обычный вопрос как high, соответствующая строка показывает FAIL, а job краснеет. Перед тем как трактовать красный job как баг модели, убедитесь, что сравниваются значения одной и той же ревизии кода и одной и той же фикстуры. Не подменяйте ожидаемое значение фактически полученным: такое «исправление» отключит сигнал регрессии.

Разбор ошибок и ограничения

Если workflow не появляется в Actions, сперва проверьте расположение YAML и событие on; затем проверьте ограничения по путям и веткам. Если job есть, но падает на checkout или setup-python, отличайте инфраструктурную ошибку от провала прикладного утверждения. Если Python завершился с ошибкой импорта, проверьте реальные пути и зависимости. Если проблема только в содержании ответа, сохраните минимальный безопасный вход и точное различие ожидаемого и фактического полей.