PyTorch Cross-Repository CI Relay (CRCR) решает конкретную проблему: изменения в pytorch/pytorch могут сломать out-of-tree backend, но его тесты живут в другом репозитории и раньше не имели стандартного канала обратно в upstream CI.

CRCR принимает событие pull request или push, отправляет repository_dispatch разрешённым downstream-репозиториям, а затем принимает аутентифицированные callbacks. Итог виден в PyTorch CI HUD.

Поток данных

1. GitHub отправляет подписанный webhook в relay.
2. Relay сверяется с allowlist и создаёт состояние DISPATCHED.
3. Downstream workflow получает событие, собирает PyTorch на нужном SHA и запускает собственные тесты.
4. Composite action отправляет in_progress, затем completed.
5. Callback проходит проверки, после чего данные попадают в HUD.

В официальном описании используются Webhook Lambda и Callback Lambda на Python 3.12, Redis для состояния и rate limiting, DynamoDB как основное хранилище, ClickHouse для аналитических запросов и Next.js HUD API.

Четыре уровня участия

Уровень	Что получает upstream
L1	только dispatch в downstream, без обратного результата
L2	результат отображается в HUD
L3	non-blocking check в PR при специальном label
L4	blocking check для каждого PR; уровень для критичных backend

L3 и L4 в официальном анонсе обозначены как будущие возможности. Это исправляет ошибку прошлой версии статьи, где L3 назывался blocking, а L4 — неопределённым резервом.

Пять проверок callback

OIDC identity. GitHub выпускает короткоживущий RS256-токен с audience pytorch-cross-repo-ci-relay. Claim repository определяет реального отправителя.

Allowlist. Только явно разрешённые репозитории уровня L2 и выше могут вернуть результат в HUD.

Rate limiting. Sliding window ограничивает поток callback от одного репозитория; при недоступном Redis система закрывается с ошибкой, а не пропускает запрос.

State machine. Разрешена последовательность DISPATCHED → IN_PROGRESS → COMPLETED. Callback без dispatch, повтор и пропуск состояния отклоняются.

Data separation. Проверенные relay-поля и self-reported payload разделены на trusted и untrusted. HUD может доверять verified_repo, но не обязан считать честным заявленный downstream-результат.

Главная граница trust model

CRCR подтверждает кто отправил callback, но не доказывает, что тест действительно запускался и завершился заявленным статусом. Компрометированный maintainer разрешённого репозитория теоретически может сообщить success при упавшем CI.

Официальный материал называет cross-check с GitHub Check Runs API будущим улучшением. До его появления allowlist, наблюдаемость и возможность быстро удалить нарушителя ограничивают ущерб, но не превращают self-reported payload в криптографическое доказательство.

Минимальная интеграция

Downstream-проекту нужны:

• запись в публичном allowlist;
• workflow с событием repository_dispatch;
• разрешение id-token: write;
• callback action pytorch/test-infra/.github/actions/cross-repo-ci-relay-callback@main;
• отправка состояний in_progress и completed.

Точные шаги и текущие имена файлов нужно брать из актуальной документации, а не копировать старый пример без проверки.

Что проверено редакцией

Архитектура, четыре уровня, пять стадий безопасности и ограничения сверены с официальным анонсом и RFC-0050. Реальный CI внешнего backend редакция не подключала, поэтому статья не утверждает, что конкретные Intel, AMD, Apple или Qualcomm репозитории уже находятся на определённом уровне.

Дополнительный контекст: тестовая инфраструктура PyTorch, CUDA wheels для AArch64, fault tolerance в Monarch и ExecuTorch on-device.