{"meta":{"title":"Проверки состояния","intro":"Узнайте, как проверки состояния обеспечивают фиксации в соответствии с условиями репозитория, помогают проверять запросы на вытягивание, а также управлять проверками, такими как сборки, тесты и развертывания.","product":"Запросы на включение внесенных изменений","breadcrumbs":[{"href":"/ru/pull-requests","title":"Запросы на включение внесенных изменений"},{"href":"/ru/pull-requests/reference","title":"Справочные материалы"},{"href":"/ru/pull-requests/reference/status-checks","title":"Проверки состояния"}],"documentType":"article"},"body":"# Проверки состояния\n\nУзнайте, как проверки состояния обеспечивают фиксации в соответствии с условиями репозитория, помогают проверять запросы на вытягивание, а также управлять проверками, такими как сборки, тесты и развертывания.\n\nПроверка состояния показывает, соответствуют ли фиксациям, заданным для репозитория. Обычно они создаются внешними системами, такими как сборки непрерывной интеграции, тесты, сканирование кода или проверки развертывания.\n\nПроверки состояния помогают рецензентам и вспомогательным лицам понять, готов ли запрос на вытягивание для слияния. Проверка может показать, что работа по-прежнему выполняется, что изменения прошли проверку или что-то требует внимания.\n\n![Снимок экрана: список фиксаций и состояний.](/assets/images/help/pull_requests/commit-list-statuses.png)\n\nЛюбой, у кого есть разрешения на запись в репозиторий, может установить состояние для любой проверки состояния в репозитории.\n\nЕсли проверки состояния необходимы для защищенной ветви, они должны пройти перед объединением запроса на вытягивание. См [. раздел AUTOTITLE](/ru/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches#require-status-checks-before-merging).\n\n> \\[!NOTE]\n> Задание, пропущенное, сообщает о своем состоянии как \"Успешно\". Это не помешает слиянию запроса на вытягивание, даже если это обязательная проверка.\n\n## Типы проверок состояния GitHub\n\nСуществует два типа проверок состояния:GitHub\n\n| Type                                 | Уровень детализации                             | Кем создано                  |\n| ------------------------------------ | ----------------------------------------------- | ---------------------------- |\n| Чеки                                 | Подробные выходные данные, заметки и сообщения. |                              |\n| GitHub Apps, включая GitHub Actions. |                                                 |                              |\n| Состояния фиксаций                   | Более простое состояние фиксации.               | Внешние службы и интеграции. |\n\n> \\[!NOTE]\n> GitHub Actions создает проверки, а не фиксирует состояния при выполнении рабочих процессов.\n\nВладельцы и пользователи организации с push-доступом к репозиторию могут создавать проверки и фиксацию состояний с помощью GitHubAPI. См. раздел \\[AUTOTITLE и [Конечные точки REST API для проверок](/ru/rest/checks)]\\(/rest/commits/statuses).\n\n## Чеки\n\nПроверки могут включать журналы сборки, результаты теста, заметки и ссылки на дополнительные сведения. В запросе на вытягивание вкладка **\"Проверки** \" помогает понять, какие проверки выполнялись и почему проверка прошла или завершилась сбоем.\n\n![Снимок экрана: вкладка \"Проверки\" запроса на вытягивание. Вкладка \"Проверки\" и раскрывающееся меню, чтобы выбрать фиксацию, описаны в темно-оранжевый цвет.](/assets/images/help/pull_requests/checks-summary-for-various-commits.png)\n\n> \\[!NOTE]\n> Вкладка **\"Проверки** \" заполняется запросами на вытягивание, только если *настроены проверки*, а не *состояния фиксации* для репозитория.\n\nЕсли флажки указывают на определенную строку, сведения также могут отображаться на вкладке **\"Файлы** \" запроса на вытягивание. Это помогает рецензентам подключать автоматические отзывы к измененным кодом.\n\n## Пропуск и запрос проверок для отдельных фиксаций\n\nНекоторые репозитории позволяют пропускать или запрашивать проверки для отдельных фиксаций. Это может быть полезно, если проверка не относится к определенному изменению или когда проверки не запрашиваются автоматически.\n\nДля GitHub Actions рабочих процессов можно пропустить запуски рабочего процесса, активировав `push` события, `pull_request` включив инструкцию пропуска в сообщение фиксации. См [. раздел AUTOTITLE](/ru/actions/how-tos/manage-workflow-runs/skip-workflow-runs).\n\nКроме того, чтобы пропустить или запросить *все* проверки фиксации, добавьте одну из следующих строк трейлера в конец сообщения фиксации:\n\n* Чтобы *пропустить проверки* для фиксации, введите сообщение о фиксации и краткое содержательное описание изменений. После описания фиксации перед закрывающим цитированием добавьте две пустые строки, за которыми следует `skip-checks: true`:\n\n  ```shell\n  $ git commit -m \"Update README\n  >\n  >\n  skip-checks: true\"\n  ```\n\n* Для *запроса* проверок фиксации введите сообщение о фиксации и краткое содержательное описание изменений. После описания фиксации перед закрывающим цитированием добавьте две пустые строки, за которыми следует `request-checks: true`:\n\n  ```shell\n  $ git commit -m \"Refactor usability tests\n  >\n  >\n  request-checks: true\"\n  ```\n\nПо умолчанию Git автоматически удаляет последовательные новые строки. Чтобы оставить сообщение фиксации точно так же, как вы ввели его, используйте `--cleanup=verbatim` параметр в фиксации. Дополнительные сведения см. в разделе [`--cleanup=<mode>`](https://git-scm.com/docs/git-commit#Documentation/git-commit.txt---cleanupltmodegt) документации.\n\n## Проверка состояний и выводов\n\nПроверяет состояние перемещения по мере их выполнения, а затем получает заключение по завершении. Некоторые состояния нельзя задать вручную и зарезервированы для GitHub Actions.\n\n\\| Status | Description |\nGitHub Actions только? |\n\\| --- | --- | --- |\n\\| `completed` | Выполнение проверки завершено и содержит вывод (см. ниже). | No |\n\\| `expected` | Выполнение проверки ожидает сообщения о состоянии. | Yes |\n\\| `failure` | Сбой выполнения проверки. | No |\n\\| `in_progress` | Выполнение проверки выполняется. | No |\n\\| `pending` | Выполнение проверки находится в передней части очереди, но [достигнуто ограничение параллелизма](/ru/actions/how-tos/write-workflows/choose-when-workflows-run/control-workflow-concurrency) на основе группы. | Yes |\n\\| `queued` | Выполнение проверки было в очереди. | No |\n\\| `requested` | Запуск проверки был создан, но не был поставлен в очередь. | Yes |\n\\| `startup_failure` | Сбой набора проверок во время запуска. Это состояние неприменимо для проверки запусков. | Yes |\n\\| `waiting` | Выполнение проверки ожидает [выполнения правила](/ru/actions/how-tos/deploy/configure-and-manage-deployments/manage-environments) защиты развертывания. | Yes |\n\nЕсли проверка имеет состояние `completed`, она имеет вывод. Успешный вывод обычно означает, что проверка не блокирует слияние. Сбой, время ожидания или вывод, необходимый для действий, обычно означает, что кто-то должен просмотреть сведения, прежде чем запрос на вытягивание может объединиться.\n\n| Conclusion        | Description                                                                                                                                                                                                                                                               |\n| ----------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| `action_required` | Выполнение проверки предоставило необходимые действия после его завершения.  Дополнительные сведения см. в разделе [Использование REST API для взаимодействия с проверками](/ru/rest/guides/using-the-rest-api-to-interact-with-checks#check-runs-and-requested-actions). |\n| `cancelled`       | Выполнение проверки было отменено до его завершения.                                                                                                                                                                                                                      |\n| `failure`         | Сбой выполнения проверки.                                                                                                                                                                                                                                                 |\n| `neutral`         | Выполнение проверки завершено с нейтральным результатом. Это рассматривается как успешное выполнение зависимых проверок GitHub Actions.                                                                                                                                   |\n| `skipped`         | Выполнение проверки было пропущено. Это рассматривается как успешное выполнение зависимых проверок GitHub Actions.                                                                                                                                                        |\n| `stale`           | Выполнение проверки было отмечено устаревшим, GitHub потому что потребовалось слишком много времени.                                                                                                                                                                      |\n| `success`         | Выполнение проверки выполнено успешно.                                                                                                                                                                                                                                    |\n| `timed_out`       | Время ожидания выполнения проверки.                                                                                                                                                                                                                                       |\n\n## Хранение проверок\n\nGitHub сохраняет данные в течение 400 дней. Через 400 дней данные архивируются. Через 10 дней после архивации данные удаляются окончательно.\n\nЧтобы объединить запрос на вытягивание с проверками, необходимыми и архивными, необходимо повторно запустить проверки."}