Доступные проверки состояния запроса на вытягивание

Службы Azure DevOps

Проверки состояния применяют стандарты качества путем блокировки слияний до прохождения тестов, проверки безопасности очищаются или другие условия. Azure DevOps Службы и внешние средства после проверки состояния с помощью API состояния PR.

Чтобы требовать проверку состояния в качестве политики ветвей, создайте политику в разделе "Состояние", чтобы проверить , и укажите жанр и имя проверки в формате genre/name. Затем запрос на вытягивание блокирует слияние до тех пор, пока отчеты succeededпроверки не будут выполнены.

Значения состояния и поведение слияния

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

Ценность Поведение с обязательной политикой Поведение с необязательной политикой
succeeded ✓ Разблокирует политику Информационный
failed ✗ Объединения блоков Информационный
error ✗ Объединения блоков Информационный
pending ⏳ Блоки слияния (ожидающий результат) Информационный
notApplicable ✓ Требование политики обхода Информационный
notSet ⏳ Обрабатывается как ожидающий Информационный

Note

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

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

Проверка состояния Azure DevOps первой стороны

Ниже приведены только проверки состояния, опубликованные в собственном коде Azure DevOps Services. Каждая проверка использует фиксированное значение жанра , поэтому можно настроить политику ветви до или после публикации первого состояния службы. Все остальные проверки состояния приходят из внешних служб через API состояния PR.

Расширенная безопасность GitHub для Azure DevOps

Эти проверки состояния требуют включения расширенной безопасности GitHub для включения Azure DevOps в репозитории. Проверки оценивают уязвимости безопасности, обнаруженные при сканировании кода (CodeQL), проверке зависимостей и проверке секретов.

Жанр Имя. Состояние проверка Description
AdvancedSecurity AllHighAndCritical AdvancedSecurity/AllHighAndCritical Блокирует слияние, если в репозитории существует любая неразрешенная критически важная уязвимость или уязвимость с высоким уровнем серьезности из любого типа сканирования (код, зависимость или секрет). Требуется политика проверки сборки с включенными задачами конвейера расширенной безопасности.
AdvancedSecurity NewHighAndCritical AdvancedSecurity/NewHighAndCritical Блокирует слияние при появлении запроса на вытягивание новых критических или критических уязвимостей с высоким уровнем серьезности из любого типа сканирования. Существующие уязвимости репозитория не блокируют слияние. Требуется политика проверки сборки с задачами конвейера расширенной безопасности для сканирования ветви PR.

Note

Обе AdvancedSecurity проверки состояния требуют политики проверки сборки и задач расширенной проверки безопасности, настроенных для Wait for Processing: true обеспечения соответствия состояниям последних результатов сканирования. Для проверки зависимостей или сканирования кода (CodeQL) включите Wait for ProcessingAdvancedSecurity-Publish задачу. Для сканирования кода также включите его в AdvancedSecurity-CodeQL-Analyze задаче. Оба проверки отображаются в раскрывающемся списке "Состояние", чтобы проверить первый успешный запуск конвейера с помощью расширенной проверки безопасности.

Tip

Если репозиторий имеет неразрешенные оповещения, начните с AdvancedSecurity/NewHighAndCritical того, чтобы избежать блокировки всех запросов на вытягивание немедленно. Миграция на AdvancedSecurity/AllHighAndCritical после устранения невыполненной работы оповещений.

Инструкции по настройке см. в разделе "Настройка проверок состояния запроса на вытягивание".

Important

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

покрытие кода Azure Pipelines

Azure Pipelines автоматически отправляет проверку состояния покрытия кода, когда конвейер публикует результаты покрытия кода для запроса на вытягивание. Жанр — это имя конвейера, поэтому точное genre/name значение зависит от того, как вы назвали конвейер.

Жанр Имя. Состояние проверка Description
{pipeline-name} codecoverage {pipeline-name}/codecoverage Сообщает процент покрытия диффа для строк, измененных в запросе на вытягивание. Рекомендации по умолчанию; не блокирует слияние, если только не настроена в качестве обязательной политики ветви с минимальным пороговым значением покрытия.

Порог передачи по умолчанию составляет 70% охвата. Чтобы настроить пороговое значение и другие параметры, добавьте azurepipelines-coverage.yml файл в корневой каталог репозитория:

coverage:
  status:
    comments: on
    diff:
      target: 80

Замените 80 нужным минимальным процентом охвата.

Инструкции по настройке см. в разделе "Принудительное применение защиты ветви" с помощью политики покрытия кода.

Tip

Жанр является производным от отображаемого имени конвейера в Azure Pipelines; оно не является отдельно настраиваемым значением. Например, конвейер с именем CI — Main используется CI - Main/codecoverage в качестве состояния для проверки значения. Проверки состояния отображаются только в раскрывающемся списке после того, как служба опубликовала хотя бы одно состояние в запрос на вытягивание. Для новых интеграции, которые еще не выполнялись, введите genre/name значение непосредственно в поле.

Пользовательские и внешние проверки состояния

Любая служба, использующая API состояния PR , может отправлять проверку состояния в запросы на вытягивание. Чтобы опубликовать проверку состояния через REST API, вызывающему удостоверению требуется разрешение на запросы на вытягивание в репозитории.

Когда служба публикует состояние, его genre/name отображается в раскрывающемся списке "Состояние" для проверки при добавлении политики. Для новых служб, которые еще не размещены, введите значение напрямую genre/name .

Общие шаблоны интеграции

Тип интеграции Description Examples
Сборка и тестирование серверов Внешние средства CI, которые после передачи или сбоя результатов после выполнения тестов в ветви PR. Дженкинс, GitLab CI, CircleCI, Travis CI
Анализ качества кода Статические средства анализа, которые сканируют код на наличие ошибок, уязвимостей и запах кода. SonarQube, SonarCloud
Сканеры безопасности Не Microsoft сканеры уязвимостей, которые публикуют результаты после сканирования изменений PR. Также поддерживает результаты формата SARIF. Snyk, Checkmarx, WhiteSource (Mend), Microsoft Security DevOps
Соответствие требованиям и политика Средства применения политик, которые проверяют лицензирование, стандарты кода, нормативные требования или готовность к развертыванию. Пользовательские средства проверки соответствия требованиям, шлюзы развертывания, сканеры лицензий
GitHub Actions Проверка рабочих процессов GitHub Actions отображается в Azure DevOps PR при подключении репозитория к GitHub. Сведения о конфигурации см. в Azure DevOps GitHub интеграции. Любой рабочий процесс GitHub Actions может публиковать состояние
Утверждения и ворота Службы, требующие ручного или автоматического утверждения перед разрешением слиянием. ServiceNow, пользовательские службы утверждения через REST API

Параметры конфигурации политики

При добавлении политики проверки состояния можно настроить следующее:

  • Требование политики: задайте политику по мере необходимости (блоки объединяются, если проверка не проходит) или необязательный (только информационный).
  • Авторизованное удостоверение: ограничить, какие учетные записи могут публиковать значения состояния, удовлетворяющие политике. Оставьте пустым, чтобы разрешить любую учетную запись.
  • Условия сброса: укажите, сбрасывается ли состояние при отправке новой фиксации. По умолчанию принудительная отправка новой фиксации сбрасывает необходимые проверки состояния в ожидание, заставляя их оценивать последний код. Чтобы разрешить сохранение состояния в фиксациях, отключите состояние сброса всякий раз при наличии новых изменений.
  • Применимость политики. Выберите, применяется ли политика немедленно (применить по умолчанию) или только после публикации первого состояния (условно).
    • Применяется по умолчанию: блоки политики объединяются до публикации succeeded состояния. Вы можете опубликовать, notApplicable чтобы обойти требование для конкретного PR.
    • Условный: политика становится активной только после того, как проверка публикует свое первое состояние.
  • Фильтр пути. Ограничение политики на PR, которые изменяют файлы в определенных путях (необязательно).

Чтобы реализовать настраиваемую проверку состояния, см. следующие сведения:

Связанные материалы

  • Last updated on