Интеграция с CI

Общие сведения

Внешние (OOT) бэкенды ускорителей должны поддерживать совместимость с постоянно развивающейся кодовой базой PyTorch. По мере быстрого развития PyTorch изменения в вышестоящем репозитории могут нарушить интеграцию с нижестоящими ускорителями. Для решения этой задачи PyTorch предоставляет механизм Cross-Repository CI Relay (CRCR), который обеспечивает автоматическую координацию CI между репозиторием PyTorch и репозиториями сторонних разработчиков ускорителей.

В этой главе описан процесс интеграции репозиториев сторонних разработчиков ускорителей с экосистемой CI PyTorch, позволяющий непрерывно проверять совместимость.

Почему важна интеграция с CI

Интеграция с экосистемой CI PyTorch дает несколько важных преимуществ:

• Раннее обнаружение: выявляйте проблемы совместимости до того, как они попадут в рабочую среду, сокращая затраты на отладку и влияние на пользователей.
• Автоматизированная проверка: автоматически тестируйте свой ускоритель на PR PyTorch без ручного вмешательства.
• Снижение затрат на сопровождение: упреждающее тестирование уменьшает необходимость в срочных исправлениях при нарушении совместимости.

Как это работает

Система CRCR состоит из четырех компонентов: приложения GitHub, которое обеспечивает взаимодействие с аутентификацией и событиями; репозитория PyTorch как источника вышестоящих событий; сервера ретрансляции, который отправляет события подходящим нижестоящим репозиториям; и нижестоящих репозиториев, которые получают события и при необходимости отправляют результаты обратно.

Когда в PyTorch открывают или обновляют PR, GitHub уведомляет сервер ретрансляции через приложение GitHub. Сервер ретрансляции проверяет событие, считывает список разрешений и отправляет событие repository_dispatch в каждый зарегистрированный нижестоящий репозиторий. Нижестоящие репозитории могут при необходимости отправлять результаты CI обратно на сервер ретрансляции, который отображает их в HUD PyTorch или в виде проверок PR.

        flowchart TD
    PyTorch["PyTorch<br/>(PR Event)"] -->|webhook| RS["Relay Server<br/>(Allowlist/Dispatch/Callback)"]
    GH["GitHub APP<br/>(Auth&Bridge)"] <--> RS
    RS <--> HUD["HUD<br/>(Dashboard)"]
    RS -->|repo_dispatch| DA[Downstream A]
    RS -->|repo_dispatch| DB[Downstream B]
    RS -->|repo_dispatch| DC[Downstream C]
    DA -->|callback| RS
    DB -->|callback| RS
    DC -->|callback| RS
    

Участие регулируется списком разрешений из четырех уровней:

• L1: события пересылаются в нижестоящий репозиторий; результаты не отправляются обратно в вышестоящий репозиторий.
• L2: результаты отображаются на отдельных страницах HUD нижестоящего репозитория.
• L3: в PR PyTorch отображаются неблокирующие проверки, запускаемые по меткам сопровождающих.
• L4: блокирующие проверки запускаются для всех PR PyTorch (уровень предназначен для критически важных ускорителей).

Нижестоящие репозитории переходят на следующие уровни, выполняя документированные требования к проверке оборудования, надежности CI и показателям успешности.

Подробное описание архитектуры и проектных решений см. в документе RFC-0050: ретрансляция CI между репозиториями для внешних бэкендов PyTorch.

Этапы интеграции

L1:
  - your-org/your-accelerator

name: PyTorch CI

run-name: >-
  PyTorch CI -
  ${{
    github.event.client_payload.event_type == 'pull_request' &&
    format('PR #{0} ({1})',
      github.event.client_payload.payload.pull_request.number,
      github.event.client_payload.payload.action) ||
    format('Push {0}', github.event.client_payload.payload.after)
  }}

on:
  repository_dispatch:
    types: [pull_request, push]

concurrency:
  group: >-
    pytorch-ci-${{ github.event.client_payload.payload.repository.full_name }}-${{
    github.event.client_payload.payload.pull_request.number || github.run_id }}
  cancel-in-progress: true

permissions:
  contents: read

jobs:
  cancel-workflow:
    if: ${{ github.event.client_payload.payload.action == 'closed' }}
    runs-on: ubuntu-latest
    steps:
      - run: echo "PR closed, canceling in-progress runs"

  ci:
    if: ${{ github.event.client_payload.payload.action != 'closed' }}
    runs-on: ubuntu-latest
    steps:
      - name: Checkout downstream repo
        uses: actions/checkout@v4

      - name: Checkout PyTorch at triggered commit
        uses: actions/checkout@v4
        with:
          repository: pytorch/pytorch
          ref: >-
            ${{ github.event.client_payload.event_type == 'pull_request' &&
            github.event.client_payload.payload.pull_request.head.sha ||
            github.event.client_payload.payload.after }}
          path: pytorch

      - name: Build and test
        run: |
          # Your build and test commands
          echo "Running tests against PyTorch..."

Данные события

Ретранслятор CRCR работает как посредник без сохранения состояния: он пересылает полную полезную нагрузку веб-перехватчика GitHub в виде client_payload в событии repository_dispatch. Упрощенная промежуточная схема не используется.

Объект client_payload содержит два поля верхнего уровня:

• event_type: либо pull_request, либо push
• payload: исходная полезная нагрузка веб-перехватчика GitHub для этого типа события

Часто используемые поля:

github.event.client_payload.event_type                       # "pull_request" or "push"
github.event.client_payload.payload.action                   # "opened", "synchronize", "reopened" or "closed" only
github.event.client_payload.payload.pull_request.number      # PR number (pull_request events only)
github.event.client_payload.payload.pull_request.head.sha    # Head commit SHA to checkout
github.event.client_payload.payload.after                    # Commit SHA (push events only)

Поддерживаемые значения action для событий pull_request:

Устранение неполадок

Ресурсы

• RFC-0050: ретрансляция CI между репозиториями для внешних бэкендов PyTorch