Проверка состояния показывает, соответствуют ли фиксациям, заданным для репозитория. Обычно они создаются внешними системами, такими как сборки непрерывной интеграции, тесты, сканирование кода или проверки развертывания.
Проверки состояния помогают рецензентам и вспомогательным лицам понять, готов ли запрос на вытягивание для слияния. Проверка может показать, что работа по-прежнему выполняется, что изменения прошли проверку или что-то требует внимания.
Любой, у кого есть разрешения на запись в репозиторий, может установить состояние для любой проверки состояния в репозитории.
Если проверки состояния необходимы для защищенной ветви, они должны пройти перед объединением запроса на вытягивание. См . раздел AUTOTITLE.
Примечание.
Задание, пропущенное, сообщает о своем состоянии как "Успешно". Это не помешает слиянию запроса на вытягивание, даже если это обязательная проверка.
Типы проверок состояния GitHub
Существует два типа проверок состояния:GitHub
| Type | Уровень детализации | Кем создано |
|---|---|---|
| Чеки | Подробные выходные данные, заметки и сообщения. | |
| GitHub Apps, включая GitHub Actions. | ||
| Состояния фиксаций | Более простое состояние фиксации. | Внешние службы и интеграции. |
Примечание.
GitHub Actions создает проверки, а не фиксирует состояния при выполнении рабочих процессов.
Владельцы и пользователи организации с push-доступом к репозиторию могут создавать проверки и фиксацию состояний с помощью GitHubAPI. См. раздел [AUTOTITLE и Конечные точки REST API для проверок](/rest/commits/statuses).
Чеки
Проверки могут включать журналы сборки, результаты теста, заметки и ссылки на дополнительные сведения. В запросе на вытягивание вкладка "Проверки " помогает понять, какие проверки выполнялись и почему проверка прошла или завершилась сбоем.
Примечание.
Вкладка "Проверки " заполняется запросами на вытягивание, только если настроены проверки, а не состояния фиксации для репозитория.
Если флажки указывают на определенную строку, сведения также могут отображаться на вкладке "Файлы " запроса на вытягивание. Это помогает рецензентам подключать автоматические отзывы к измененным кодом.
Пропуск и запрос проверок для отдельных фиксаций
Некоторые репозитории позволяют пропускать или запрашивать проверки для отдельных фиксаций. Это может быть полезно, если проверка не относится к определенному изменению или когда проверки не запрашиваются автоматически.
Для GitHub Actions рабочих процессов можно пропустить запуски рабочего процесса, активировав push события, pull_request включив инструкцию пропуска в сообщение фиксации. См . раздел AUTOTITLE.
Кроме того, чтобы пропустить или запросить все проверки фиксации, добавьте одну из следующих строк трейлера в конец сообщения фиксации:
-
Чтобы пропустить проверки для фиксации, введите сообщение о фиксации и краткое содержательное описание изменений. После описания фиксации перед закрывающим цитированием добавьте две пустые строки, за которыми следует
skip-checks: true:$ git commit -m "Update README > > skip-checks: true" -
Для запроса проверок фиксации введите сообщение о фиксации и краткое содержательное описание изменений. После описания фиксации перед закрывающим цитированием добавьте две пустые строки, за которыми следует
request-checks: true:$ git commit -m "Refactor usability tests > > request-checks: true"
По умолчанию Git автоматически удаляет последовательные новые строки. Чтобы оставить сообщение фиксации точно так же, как вы ввели его, используйте --cleanup=verbatim параметр в фиксации. Дополнительные сведения см. в разделе --cleanup=<mode> документации.
Проверка состояний и выводов
Проверяет состояние перемещения по мере их выполнения, а затем получает заключение по завершении. Некоторые состояния нельзя задать вручную и зарезервированы для GitHub Actions.
| Status | Description |
GitHub Actions только? |
| --- | --- | --- |
| completed | Выполнение проверки завершено и содержит вывод (см. ниже). | No |
| expected | Выполнение проверки ожидает сообщения о состоянии. | Yes |
| failure | Сбой выполнения проверки. | No |
| in_progress | Выполнение проверки выполняется. | No |
| pending | Выполнение проверки находится в передней части очереди, но достигнуто ограничение параллелизма на основе группы. | Yes |
| queued | Выполнение проверки было в очереди. | No |
| requested | Запуск проверки был создан, но не был поставлен в очередь. | Yes |
| startup_failure | Сбой набора проверок во время запуска. Это состояние неприменимо для проверки запусков. | Yes |
| waiting | Выполнение проверки ожидает выполнения правила защиты развертывания. | Yes |
Если проверка имеет состояние completed, она имеет вывод. Успешный вывод обычно означает, что проверка не блокирует слияние. Сбой, время ожидания или вывод, необходимый для действий, обычно означает, что кто-то должен просмотреть сведения, прежде чем запрос на вытягивание может объединиться.
| Conclusion | Description |
|---|---|
action_required | Выполнение проверки предоставило необходимые действия после его завершения. Дополнительные сведения см. в разделе Использование REST API для взаимодействия с проверками. |
cancelled | Выполнение проверки было отменено до его завершения. |
failure | Сбой выполнения проверки. |
neutral | Выполнение проверки завершено с нейтральным результатом. Это рассматривается как успешное выполнение зависимых проверок GitHub Actions. |
skipped | Выполнение проверки было пропущено. Это рассматривается как успешное выполнение зависимых проверок GitHub Actions. |
stale | Выполнение проверки было отмечено устаревшим, GitHub потому что потребовалось слишком много времени. |
success | Выполнение проверки выполнено успешно. |
timed_out | Время ожидания выполнения проверки. |
Хранение проверок
Администраторы сайта могут контролировать политику хранения для проверки данных ваш экземпляр GitHub Enterprise Server. Дополнительные сведения см. в разделе Настройка приложений.
Чтобы объединить запрос на вытягивание с проверками, необходимыми и архивными, необходимо повторно запустить проверки.