Сведения о проверках состояния

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

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

Общее состояние последней фиксации в ветви можно увидеть на странице ветвей репозитория или в списке запросов на вытягивание репозитория.

Если для репозитория требуются проверки состояния, перед объединением ветви в защищенную ветвь необходимо пройти проверку состояния. Дополнительные сведения см. в разделе Сведения о защищенных ветвях.

Типы проверок состояния на GitHub Enterprise Cloud

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

• Проверки
• Состояния фиксаций

Проверки отличаются от состояний фиксации в том, что они предоставляют заметки строки, более подробные сообщения и доступны только для использования с GitHub Apps.

Владельцы и пользователи организации с доступ на отправку в репозиторий могут создавать проверки и фиксацию состояний с помощью API GitHub Enterprise Cloud. Дополнительные сведения см. в разделе "[AUTOTITLE" и "Конечные точки REST API для проверка](/rest/commits/statuses)".

Проверки

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

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

Вы можете перемещаться между сводками проверок для различных фиксаций в запросе на вытягивание, используя раскрывающееся меню фиксации на вкладке "Проверки ".

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

Если репозиторий настроен на автоматический запрос проверки для отправки, можно пропустить проверки для отдельной фиксации, отправленной вами. Если репозиторий не настроен на автоматический запрос проверки для отправки, можно запросить проверки для отдельной фиксации, отправленной вами. Дополнительные сведения об этих параметрах см. в разделе "Конечные точки REST API для наборов проверка".

Вы также можете пропустить выполнение рабочего процесса, активированного событиями push , pull_request включив команду в сообщение фиксации. Дополнительные сведения см. в разделе "Пропуск запусков рабочих процессов"

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

• Чтобы пропустить проверки для фиксации, введите сообщение о фиксации и краткое содержательное описание изменений. После описания фиксации перед закрывающим цитированием добавьте две пустые строки, за которыми следует 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 сохраняет данные в течение 400 дней. Через 400 дней данные архивируются. Через 10 дней после архивации данные удаляются окончательно.

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