# Проверки состояния

Узнайте, как проверки состояния обеспечивают фиксации в соответствии с условиями репозитория, помогают проверять запросы на вытягивание, а также управлять проверками, такими как сборки, тесты и развертывания.

Проверка состояния показывает, соответствуют ли фиксациям, заданным для репозитория. Обычно они создаются внешними системами, такими как сборки непрерывной интеграции, тесты, сканирование кода или проверки развертывания.

Проверки состояния помогают рецензентам и вспомогательным лицам понять, готов ли запрос на вытягивание для слияния. Проверка может показать, что работа по-прежнему выполняется, что изменения прошли проверку или что-то требует внимания.

![Снимок экрана: список фиксаций и состояний.](/assets/images/help/pull_requests/commit-list-statuses.png)

Любой, у кого есть разрешения на запись в репозиторий, может установить состояние для любой проверки состояния в репозитории.

Если проверки состояния необходимы для защищенной ветви, они должны пройти перед объединением запроса на вытягивание. См [. раздел AUTOTITLE](/ru/enterprise-server@3.17/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches#require-status-checks-before-merging).

> \[!NOTE]
> Задание, пропущенное, сообщает о своем состоянии как "Успешно". Это не помешает слиянию запроса на вытягивание, даже если это обязательная проверка.

## Типы проверок состояния GitHub

Существует два типа проверок состояния:GitHub

| Type                                 | Уровень детализации                             | Кем создано                  |
| ------------------------------------ | ----------------------------------------------- | ---------------------------- |
| Чеки                                 | Подробные выходные данные, заметки и сообщения. |                              |
| GitHub Apps, включая GitHub Actions. |                                                 |                              |
| Состояния фиксаций                   | Более простое состояние фиксации.               | Внешние службы и интеграции. |

> \[!NOTE]
> GitHub Actions создает проверки, а не фиксирует состояния при выполнении рабочих процессов.

Владельцы и пользователи организации с push-доступом к репозиторию могут создавать проверки и фиксацию состояний с помощью GitHubAPI. См. раздел \[AUTOTITLE и [Конечные точки REST API для проверок](/ru/enterprise-server@3.17/rest/checks)]\(/rest/commits/statuses).

## Чеки

Проверки могут включать журналы сборки, результаты теста, заметки и ссылки на дополнительные сведения. В запросе на вытягивание вкладка **"Проверки** " помогает понять, какие проверки выполнялись и почему проверка прошла или завершилась сбоем.

![Снимок экрана: вкладка "Проверки" запроса на вытягивание. Вкладка "Проверки" и раскрывающееся меню, чтобы выбрать фиксацию, описаны в темно-оранжевый цвет.](/assets/images/help/pull_requests/checks-summary-for-various-commits.png)

> \[!NOTE]
> Вкладка **"Проверки** " заполняется запросами на вытягивание, только если *настроены проверки*, а не *состояния фиксации* для репозитория.

Если флажки указывают на определенную строку, сведения также могут отображаться на вкладке **"Файлы** " запроса на вытягивание. Это помогает рецензентам подключать автоматические отзывы к измененным кодом.

## Пропуск и запрос проверок для отдельных фиксаций

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

Для GitHub Actions рабочих процессов можно пропустить запуски рабочего процесса, активировав `push` события, `pull_request` включив инструкцию пропуска в сообщение фиксации. См [. раздел AUTOTITLE](/ru/enterprise-server@3.17/actions/how-tos/manage-workflow-runs/skip-workflow-runs).

Кроме того, чтобы пропустить или запросить *все* проверки фиксации, добавьте одну из следующих строк трейлера в конец сообщения фиксации:

* Чтобы *пропустить проверки* для фиксации, введите сообщение о фиксации и краткое содержательное описание изменений. После описания фиксации перед закрывающим цитированием добавьте две пустые строки, за которыми следует `skip-checks: true`:

  ```shell
  $ git commit -m "Update README
  >
  >
  skip-checks: true"
  ```

* Для *запроса* проверок фиксации введите сообщение о фиксации и краткое содержательное описание изменений. После описания фиксации перед закрывающим цитированием добавьте две пустые строки, за которыми следует `request-checks: true`:

  ```shell
  $ git commit -m "Refactor usability tests
  >
  >
  request-checks: true"
  ```

По умолчанию Git автоматически удаляет последовательные новые строки. Чтобы оставить сообщение фиксации точно так же, как вы ввели его, используйте `--cleanup=verbatim` параметр в фиксации. Дополнительные сведения см. в разделе [`--cleanup=<mode>`](https://git-scm.com/docs/git-commit#Documentation/git-commit.txt---cleanupltmodegt) документации.

## Проверка состояний и выводов

Проверяет состояние перемещения по мере их выполнения, а затем получает заключение по завершении. Некоторые состояния нельзя задать вручную и зарезервированы для GitHub Actions.

\| Status | Description |
GitHub Actions только? |
\| --- | --- | --- |
\| `completed` | Выполнение проверки завершено и содержит вывод (см. ниже). | No |
\| `expected` | Выполнение проверки ожидает сообщения о состоянии. | Yes |
\| `failure` | Сбой выполнения проверки. | No |
\| `in_progress` | Выполнение проверки выполняется. | No |
\| `pending` | Выполнение проверки находится в передней части очереди, но [достигнуто ограничение параллелизма](/ru/enterprise-server@3.17/actions/how-tos/write-workflows/choose-when-workflows-run/control-workflow-concurrency) на основе группы. | Yes |
\| `queued` | Выполнение проверки было в очереди. | No |
\| `requested` | Запуск проверки был создан, но не был поставлен в очередь. | Yes |
\| `startup_failure` | Сбой набора проверок во время запуска. Это состояние неприменимо для проверки запусков. | Yes |
\| `waiting` | Выполнение проверки ожидает [выполнения правила](/ru/enterprise-server@3.17/actions/how-tos/deploy/configure-and-manage-deployments/manage-environments) защиты развертывания. | Yes |

Если проверка имеет состояние `completed`, она имеет вывод. Успешный вывод обычно означает, что проверка не блокирует слияние. Сбой, время ожидания или вывод, необходимый для действий, обычно означает, что кто-то должен просмотреть сведения, прежде чем запрос на вытягивание может объединиться.

| Conclusion        | Description                                                                                                                                                                                                                                                                                      |
| ----------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| `action_required` | Выполнение проверки предоставило необходимые действия после его завершения.  Дополнительные сведения см. в разделе [Использование REST API для взаимодействия с проверками](/ru/enterprise-server@3.17/rest/guides/using-the-rest-api-to-interact-with-checks#check-runs-and-requested-actions). |
| `cancelled`       | Выполнение проверки было отменено до его завершения.                                                                                                                                                                                                                                             |
| `failure`         | Сбой выполнения проверки.                                                                                                                                                                                                                                                                        |
| `neutral`         | Выполнение проверки завершено с нейтральным результатом. Это рассматривается как успешное выполнение зависимых проверок GitHub Actions.                                                                                                                                                          |
| `skipped`         | Выполнение проверки было пропущено. Это рассматривается как успешное выполнение зависимых проверок GitHub Actions.                                                                                                                                                                               |
| `stale`           | Выполнение проверки было отмечено устаревшим, GitHub потому что потребовалось слишком много времени.                                                                                                                                                                                             |
| `success`         | Выполнение проверки выполнено успешно.                                                                                                                                                                                                                                                           |
| `timed_out`       | Время ожидания выполнения проверки.                                                                                                                                                                                                                                                              |

## Хранение проверок

Администраторы сайта могут контролировать политику хранения для проверки данных ваш экземпляр GitHub Enterprise Server. Дополнительные сведения см. в разделе [Настройка приложений](/ru/enterprise-server@3.17/admin/configuring-settings/configuring-user-applications-for-your-enterprise/configuring-applications#enabling-retention-policy-for-checks).

Чтобы объединить запрос на вытягивание с проверками, необходимыми и архивными, необходимо повторно запустить проверки.