Как запустить ручной smoke-тест AI API через GitHub Actions и секреты

Нужен репозиторий 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. Создайте repository secret AI_API_KEY в настройках Actions согласно официальному руководству, а URL измените на тестовый адрес собственного сервиса. Сохраните скрипт из блока ниже; заголовок Authorization должен соответствовать вашему API, поэтому его формат проверяется в документации вашего сервиса. Добавьте workflow в .github/workflows/ai-smoke.yml в default branch. В разделе Actions выберите AI API manual smoke, затем Run workflow. Если ключ не задан, скрипт прекращается до HTTP-запроса. Не вставляйте пользовательские персональные данные в пример и не добавляйте print(data): ответ может содержать чувствительный текст.
4. Сначала воспроизведите успешный вход, затем намеренно измените одно ожидаемое значение и убедитесь, что job падает. Проверка без негативного сценария не доказывает, что тест вообще способен обнаружить регрессию. После этого верните правильное значение и повторите запуск.
5. При сбое откройте конкретный job и шаг, а не ориентируйтесь только на общий статус workflow. Проверьте событие запуска, выбранную ветку, наличие файлов, код завершения скрипта и последние безопасные диагностические сообщения.

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

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

name: AI API manual smoke
on:
  workflow_dispatch:
permissions:
  contents: read
jobs:
  smoke:
    runs-on: ubuntu-latest
    env:
      AI_API_KEY: ${{ secrets.AI_API_KEY }}
      AI_API_URL: https://example.invalid/api/classify
    steps:
      - uses: actions/checkout@v7
      - uses: actions/setup-python@v7
        with:
          python-version: '3.13'
      - name: Check response contract
        run: python scripts/smoke_ai.py

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

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

# scripts/smoke_ai.py
import json, os, urllib.request
url = os.environ["AI_API_URL"]
key = os.environ["AI_API_KEY"]
if not key:
    raise SystemExit("AI_API_KEY is missing")
body = json.dumps({"text": "Срочно: платеж не прошёл"}).encode()
request = urllib.request.Request(url, body, {"Authorization": "Bearer " + key,
    "Content-Type": "application/json"})
with urllib.request.urlopen(request, timeout=20) as response:
    data = json.load(response)
assert data.get("priority") in {"high", "normal"}, "priority missing"
assert isinstance(data.get("summary"), str) and data["summary"], "summary missing"
print("Contract OK: priority and nonempty summary")

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

При тестовом ответе {"priority":"high","summary":"Платёж не прошёл"} ожидаем строку Contract OK: priority and nonempty summary. При ответе без summary job завершается ошибкой summary missing; отсутствие ключа даёт AI_API_KEY is missing без раскрытия значения. Перед тем как трактовать красный job как баг модели, убедитесь, что сравниваются значения одной и той же ревизии кода и одной и той же фикстуры. Не подменяйте ожидаемое значение фактически полученным: такое «исправление» отключит сигнал регрессии.

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

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

В CI тестируется выбранный контракт, а не «качество ИИ вообще». Он не доказывает отсутствие галлюцинаций, безопасность всех возможных промптов или корректность каждой интеграции. Добавляйте отдельные фикстуры для отрицательных кейсов, пустого ввода, Unicode и граничных форматов, когда эти ситуации есть в вашем продукте. Для live API ограничивайте доступ к секрету и используйте отдельные тестовые данные. Не выводите заголовки Authorization, тело закрытого ответа или переменные окружения целиком.