Как настроить ночную проверку AI-сервиса по расписанию 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. Возьмите скрипт smoke_ai.py из приведённого ниже блока и адрес своего тестового endpoint. Установите AI_API_KEY как repository secret. Положите YAML в .github/workflows/nightly-ai.yml именно в default branch; плановые события выполняются на ней. Выражение 17 2 * * * в данном шаблоне означает 02:17 UTC при отсутствии явного timezone; переведите в локальное время и учтите сезонный сдвиг, либо используйте документированное поле timezone для нужной зоны. Оставленный workflow_dispatch позволяет проверить тот же код сразу после добавления. Запишите, кто смотрит failed runs, иначе уведомление о сбое не станет действием.
4. Сначала воспроизведите успешный вход, затем намеренно измените одно ожидаемое значение и убедитесь, что job падает. Проверка без негативного сценария не доказывает, что тест вообще способен обнаружить регрессию. После этого верните правильное значение и повторите запуск.
5. При сбое откройте конкретный job и шаг, а не ориентируйтесь только на общий статус workflow. Проверьте событие запуска, выбранную ветку, наличие файлов, код завершения скрипта и последние безопасные диагностические сообщения.

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

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

name: Nightly AI API contract
on:
  schedule:
    - cron: '17 2 * * *'
  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'
      - run: python scripts/smoke_ai.py

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

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

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

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

Ожидаемый JSON на запрос Срочно: платеж не прошёл: {"priority":"high","summary":"Платёж не прошёл"}. В логе будет Nightly API contract OK; при пропаже поля priority получим Invalid priority in response. Время 02:17 — настройка самого шаблона, не измерение SLA. Перед тем как трактовать красный job как баг модели, убедитесь, что сравниваются значения одной и той же ревизии кода и одной и той же фикстуры. Не подменяйте ожидаемое значение фактически полученным: такое «исправление» отключит сигнал регрессии.

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

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

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