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