Как сделать переиспользуемый workflow AI-контракта через workflow_call

Нужен репозиторий 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-файла по путям, указанным комментариями в блоке, и тест из второго блока. Не помещайте два верхнеуровневых документа в один файл: комментарии обозначают границу файлов. В вызывающем workflow uses находится у job, а не у step; with.fixture-set передаёт строку в типизированный input. Проверяйте параметр внутри теста по белому списку имён, чтобы опечатка не приводила к неочевидному KeyError. Добавьте второй caller для ручного запуска или второй job для набора ordinary, не дублируя определение установки Python. Здесь секреты не передаются; не используйте secrets: inherit по привычке, пока он не нужен.
4. Сначала воспроизведите успешный вход, затем намеренно измените одно ожидаемое значение и убедитесь, что job падает. Проверка без негативного сценария не доказывает, что тест вообще способен обнаружить регрессию. После этого верните правильное значение и повторите запуск.
5. При сбое откройте конкретный job и шаг, а не ориентируйтесь только на общий статус workflow. Проверьте событие запуска, выбранную ветку, наличие файлов, код завершения скрипта и последние безопасные диагностические сообщения.

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

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

# .github/workflows/reusable-ai-contract.yml
name: Reusable AI contract
on:
  workflow_call:
    inputs:
      fixture-set:
        type: string
        required: true
permissions:
  contents: read
jobs:
  contract:
    runs-on: ubuntu-latest
    env:
      FIXTURE_SET: ${{ inputs.fixture-set }}
    steps:
      - uses: actions/checkout@v7
      - uses: actions/setup-python@v7
        with:
          python-version: '3.13'
      - run: python -m unittest discover -s tests -v

# .github/workflows/ai-contract-pr.yml
name: AI contract caller
on:
  pull_request:
permissions:
  contents: read
jobs:
  test-urgent:
    uses: ./.github/workflows/reusable-ai-contract.yml
    with:
      fixture-set: urgent

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

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

# tests/test_selected_fixture.py
import os, unittest

class SelectedFixture(unittest.TestCase):
    def test_routing(self):
        selected = os.environ["FIXTURE_SET"]
        fixtures = {"urgent": ("Срочно: платеж не прошёл", "high"),
                    "ordinary": ("Когда придёт чек?", "normal")}
        text, expected = fixtures[selected]
        actual = "high" if text.startswith("Срочно:") else "normal"
        self.assertEqual(actual, expected)

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

Caller передаёт urgent, скрипт выбирает Срочно: платеж не прошёл и ожидает high; workflow зелёный. Если caller укажет ordinary, тест проверит Когда придёт чек? и normal. Ошибка в actual приводит к красному job внутри reusable workflow. Перед тем как трактовать красный job как баг модели, убедитесь, что сравниваются значения одной и той же ревизии кода и одной и той же фикстуры. Не подменяйте ожидаемое значение фактически полученным: такое «исправление» отключит сигнал регрессии.

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

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