# Использование REST API для взаимодействия с проверками С помощью REST API можно создать GitHub Apps эффективные проверки изменений кода в репозитории. Вы можете создавать приложения, которые выполняют непрерывную интеграцию, структурирование кода или службы сканирования кода и предоставляют подробные отзывы о фиксациях. ## Обзор Вместо состояния двоичной передачи или сбоя сборки GitHub Apps можно сообщать о расширенных состояниях, а также создавать заметки о строках кода с подробными сведениями и повторно выполнять тесты. REST API для управления проверками доступен исключительно для ваших приложений GitHub. Пример использования REST API с параметром GitHub App[Проверка CI в здании с помощью приложения GitHub](/ru/enterprise-server@3.22/apps/creating-github-apps/writing-code-for-a-github-app/building-ci-checks-with-a-github-app#step-26-automatically-fix-rubocop-errors). Вы можете использовать состояния с [защищенная ветвь,](/ru/enterprise-server@3.22/rest/repos#branches) чтобы предотвратить преждевременное объединение запросов на вытягивание. Дополнительные сведения см. в разделе [Сведения о защищенных ветвях](/ru/enterprise-server@3.22/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches#require-status-checks-before-merging). ## Сведения о наборах проверок Когда кто-то отправляет код в репозиторий, GitHub создаёт набор проверок для последнего коммита. Чек-пакет — это набор [check runs](/ru/enterprise-server@3.22/rest/checks#check-runs) созданный одним GitHub приложением для конкретного коммита. Набор проверок позволяет получить общее заключение о состоянии выполнения проверок, входящих в состав набора. Может `status` быть`queued`, , , `in_progress``requested``waiting`, `pending`или `completed`. Только GitHub Actions может задать состояние `requested`, `waiting`или `pending`. Если состояние имеется `completed`, вывод может быть любым из следующих элементов: * `action_required` * `cancelled` * `timed_out` * `failure` * `neutral` * `skipped` * `stale` * `startup_failure` * `success` Набор проверок сообщает значение `conclusion` выполнения проверки с наивысшим приоритетом из всех значений `conclusion` набора проверок. Например, если для трех выполнений проверок получены заключения `timed_out`, `success` и `neutral`, заключением для набора проверок будет `timed_out`. По умолчанию GitHub автоматически создаёт набор чеков при отправке кода в репозиторий. Этот стандартный поток отправляет событие `check_suite` (с действием `requested`) всем GitHub приложениям, имеющим разрешение `checks:write`. Когда ваше приложение GitHub получает событие `check_suite`, оно может создавать новые проверочные забеги для последнего коммита. GitHub автоматически добавляет новые проверочные пробеги в правильный пакет [check suite](/ru/enterprise-server@3.22/rest/checks#check-suites) на основе репозитория и SHA проверки. Если вы не хотите использовать автоматический процесс по умолчанию, то можете управлять созданием наборов проверок. Чтобы изменить параметры по умолчанию для создания наборов проверок, используйте конечную точку [обновления параметров наборов проверок для репозитория](/ru/enterprise-server@3.22/rest/checks/suites#update-repository-preferences-for-check-suites). Все изменения параметров автоматического процесса записываются в журнал аудита репозитория. Если вы отключили автоматический процесс, набор проверок можно создать с помощью конечной точки [создания набора проверок](/ru/enterprise-server@3.22/rest/checks/suites#create-a-check-suite). Далее следует использовать конечную точку [создания выполнения проверки](/ru/enterprise-server@3.22/rest/checks/runs#create-a-check-run) для предоставления отзывов о фиксации. Разрешение на запись для REST API для взаимодействия с проверками доступно только для GitHub Apps. OAuth apps и прошедшие проверку подлинности пользователи могут просматривать проверки запусков и проверки наборов, но они не могут создавать их. Если вы не создаете GitHub App, вам может потребоваться использовать REST API для взаимодействия с [состояниями фиксации](/ru/enterprise-server@3.22/rest/commits#commit-statuses). Чтобы использовать конечные точки для управления наборами проверок, GitHub App необходимо иметь `checks:write` разрешение и также подписаться на веб-перехватчик [check\_suite](/ru/enterprise-server@3.22/webhooks/webhook-events-and-payloads#check_suite) . Сведения о проверке подлинности в качестве приложения GitHub см. в разделе [Об аутентификации с помощью приложения GitHub](/ru/enterprise-server@3.22/apps/creating-github-apps/authenticating-with-a-github-app/about-authentication-with-a-github-app). ## Сведения о выполнениях проверок Выполнение проверки — это отдельный тест, входящий в состав набора проверок. Каждое выполнение имеет состояние и заключение. Может `status` быть`queued`, , , `in_progress``requested``waiting`, `pending`или `completed`. Только GitHub Actions может задать состояние `requested`, `waiting`или `pending`. Если состояние имеется `completed`, вывод может быть любым из следующих элементов: * `action_required` * `cancelled` * `timed_out` * `failure` * `neutral` * `skipped` * `success` Если выполнение проверки находится в неполном состоянии более 14 дней, то выполнение проверки `conclusion` становится `stale` и отображается GitHub как устаревший. Только GitHub флажок выполняется как `stale`. Дополнительные сведения о возможных заключениях для выполнения проверки см. в [описании параметра `conclusion`](/ru/enterprise-server@3.22/rest/checks#create-a-check-run--parameters). Как только вы получите веб-перехватчик [`check_suite`](/ru/enterprise-server@3.22/webhooks/webhook-events-and-payloads#check_suite), вы можете создать выполнение проверки, даже если проверка не завершена. Вы можете изменить состояние (`status`) выполнения проверки после его завершения на значение `queued`, `in_progress` или `completed`, а также обновлять `output` по мере получения дополнительных сведений. Выполнение проверки может содержать метки времени, ссылку на дополнительные сведения на внешнем сайте, подробные заметки для определенных строк кода и сведения о проведенном анализе. Заметки добавляют сведения из проверки выполнения в определенные строки кода. Каждая заметка содержит `annotation_level` свойство, которое может быть `notice`, `warning`или `failure`. Заметка также включает `path``start_line`и `end_line` указывает расположение, к чему относится заметка. Заметка содержит описание `message` результата. Дополнительные сведения см. в разделе [Конечные точки REST API для проверки выполнения](/ru/enterprise-server@3.22/rest/checks/runs). Проверку также можно вручную запустить в интерфейсе GitHub. Дополнительные сведения см. в разделе [Проверки состояния](/ru/enterprise-server@3.22/pull-requests/collaborating-with-pull-requests/collaborating-on-repositories-with-code-quality-features/about-status-checks#checks) . При этом GitHub App созданный запуск проверки получит [`check_run`](/ru/enterprise-server@3.22/webhooks/webhook-events-and-payloads#check_run) веб-перехватчик, запрашивающий новый запуск проверки. Если вы создаете запуск проверки без создания набора GitHub , автоматически создает набор для проверки. Разрешение на запись для REST API для взаимодействия с проверками доступно только для GitHub Apps. OAuth apps и прошедшие проверку подлинности пользователи могут просматривать проверки запусков и проверки наборов, но они не могут создавать их. Если вы не создаете GitHub App, вам может потребоваться использовать REST API для взаимодействия с [состояниями фиксации](/ru/enterprise-server@3.22/rest/commits#commit-statuses). Чтобы использовать конечные точки для управления проверками, GitHub App необходимо иметь `checks:write` разрешение и также подписаться на веб-перехватчик [check\_run](/ru/enterprise-server@3.22/webhooks/webhook-events-and-payloads#check_run) . ## Выполнения проверок и запрошенные действия При настройке проверки выполнения с запрошенными действиями (не путать с GitHub Actions), можно отобразить кнопку в представлении GitHub запроса на вытягивание, чтобы пользователи могли запросить GitHub App выполнение дополнительных задач. Например, приложение для анализа кода может использовать запрошенные действия с целью отображения в запросе на вытягивание кнопки для автоматического исправления обнаруженных синтаксических ошибок. Чтобы создать кнопку для запроса дополнительных действий в приложении, используйте [объект `actions`](/ru/enterprise-server@3.22/rest/checks/runs#create-a-check-run--parameters) при [создании выполнения проверки](/ru/enterprise-server@3.22/rest/checks#create-a-check-run). Например, приведенный `actions` ниже объект отображает кнопку на **вкладке "Проверки** " запроса на вытягивание с меткой "Исправить это". Кнопка появляется после завершения выполнения проверки. ```json "actions": [{ "label": "Fix this", "description": "Let us fix that for you", "identifier": "fix_errors" }] ``` Когда пользователь нажимает кнопку, GitHub отправляет [веб-перехватчик в приложение.`check_run.requested_action`](/ru/enterprise-server@3.22/webhooks/webhook-events-and-payloads#check_run) Когда приложение получает событие веб-перехватчика `check_run.requested_action`, оно может найти ключ `requested_action.identifier` в полезных данных веб-перехватчика, чтобы определить, какая кнопка была нажата, и выполнить запрошенную задачу. Подробный пример настройки запрошенных действий с помощью REST API см. в разделе [Проверка CI в здании с помощью приложения GitHub](/ru/enterprise-server@3.22/apps/creating-github-apps/writing-code-for-a-github-app/building-ci-checks-with-a-github-app). ## Хранение данных о проверках Администраторы сайта могут контролировать политику хранения для проверки данных ваш экземпляр GitHub Enterprise Server. Дополнительные сведения см. в разделе [Настройка приложений](/ru/enterprise-server@3.22/admin/configuring-settings/configuring-user-applications-for-your-enterprise/configuring-applications#enabling-retention-policy-for-checks). Чтобы объединить запрос на вытягивание с проверками, необходимыми и архивными, необходимо повторно запустить проверки.