Настройка и расширение рабочих процессов запроса на вытягивание с помощью состояния запроса на вытягивание

Azure DevOps Services | Azure DevOps Server 2022 — Azure DevOps Server 2019

Запросы на вытягивание — это отличный инструмент для упрощения проверки кода и управления перемещением кода в репозитории. Политики ветви применяют качество кода во время процесса запроса на вытягивание, устанавливая требования, которые должны выполняться для каждого изменения кода. Эти политики позволяют командам применять множество рекомендаций, связанных с проверкой кода и выполнением автоматизированных сборок, но многие команды имеют дополнительные требования и проверки для выполнения кода. Для покрытия этих индивидуальных и пользовательских потребностей Azure Repos предлагает состояния запроса на вытягивание. Состояния запроса на вытягивание интегрируются в рабочий процесс pr и позволяют внешним службам программно выходить на изменение кода путем связывания простых сведений об успешном или неудачном типе с запросом на вытягивание. При необходимости запросы на вытягивание могут быть заблокированы до тех пор, пока внешняя служба не утвердит изменение.

Интеграция в рабочий процесс pr включает несколько различных концепций:

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

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

Состояние запроса на вытягивание

Состояние запроса на вытягивание позволяет службам связывать простые сведения о типе успешного и сбоя с запросом на вытягивание с помощью API состояния. Состояние состоит из четырех ключевых элементов данных:

• Состояние. Одно из следующих предопределенных состояний: succeeded, failed, pending, , notSetnotApplicableили error.
• Описание. Строка, описывающая состояние конечного пользователя.
• Контекст. Имя состояния— обычно описание сущности, публикующей состояние.
• URL-адрес. Ссылка, по которой пользователи могут получить дополнительные сведения о состоянии.

По сути, состояние — это способ публикации пользователем или службой оценки запроса на вытягивание и ответ на такие вопросы, как:

• Соответствуют ли изменения требованиям?
• Где можно узнать больше о том, что мне нужно сделать для удовлетворения требований?

Давайте рассмотрим пример. Рассмотрим службу CI, необходимую для сборки всех изменений кода в проекте. Когда эта служба оценивает изменения в запросе на вытягивание, необходимо опубликовать результаты сборки и тестов. Для изменений, которые передают сборку, может быть размещено состояние, подобное этому, на pr:

{
    "state": "succeeded",
    "description": "CI build succeeded",
    "context": {
        "name": "my-ci-system",
        "genre": "continuous-integration"
    },
    "targetUrl": "http://contoso.com/CI/builds/1"
}

Это состояние будет отображаться для конечного пользователя в представлении сведений о pr:

• Отображается state пользователю, используя значок (зеленый проверка для , красный X для succeeded, часов для failedpending, и красный ! для error).
• Отображается description рядом с значком и context доступен в подсказке.
• targetUrl При применении описание будет отображаться как ссылка на URL-адрес.

Обновление состояния

Служба может обновить состояние PR для одного pr, разместив дополнительные состояния, только последние из которых отображаются для каждого уникального context. Размещение нескольких состояний помогает пользователям управлять ожиданиями. Например, публикация pending состояния — хороший способ подтвердить пользователю, что система получила событие и начинает работу. Использование информативного description , например следующих примеров, может помочь пользователю понять, как работает система:

• "Сборка в очереди"
• "Выполняется сборка"
• "Сборка выполнена успешно"

Состояние итерации

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

Примечание.

Если созданный pr содержит более 100 000 измененных файлов, то по причинам производительности и стабильности, что PR не будет поддерживать итерации. Это означает, что для этого изменения будут включены дополнительные изменения, но для этого изменения не будет создано новое итерация. Кроме того, любая попытка создать состояние для несуществующей итерации вернет ошибку.

И наоборот, если состояние, размещенное в целом, применяется ко всему pr, независимо от кода, публикация в итерации может быть ненужным. Например, проверка, что автор (неизменяемое свойство PR) принадлежит определенной группе, необходимо оценить только один раз, и состояние итерации не потребуется.

При настройке политики состояния, если используется состояние итерации, условия сброса должны быть заданы для состояния сброса всякий раз при наличии новых изменений. Это еще больше гарантирует, что PR не сможет быть объединен до тех пор, пока последняя итерация не имеет статуса succeeded.

Примеры REST API для публикации состояния в итерации и запросе на вытягивание.

Политика состояния

Только при использовании состояния сведения из внешней службы могут предоставляться пользователям в рамках взаимодействия с pr. Иногда общий доступ к информации о PR необходим, но в других случаях PR следует блокировать слияние до тех пор, пока не будут выполнены требования. Как и в стандартных политиках, политика состояния позволяет внешним службам блокировать завершение pr до тех пор, пока не будут выполнены требования. Если политика требуется, она должна пройти, чтобы завершить запрос на вытягивание. Если политика является необязательной, она является информационной, и для завершения запроса на вытягивание не требуется состояние succeeded .

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

Если указана политика состояния, требуется, чтобы для передачи этой политики отображалось состояние succeeded с context соответствующим выбранным именем.

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

Возможность применения политики

Параметры применимости политики определяют, применяется ли эта политика сразу после создания запроса на вытягивание или применяется ли политика только после отправки первого состояния в запрос на вытягивание.

1. Применить по умолчанию — политика применяется сразу после создания запроса на вытягивание. С помощью этого параметра политика не проходит после создания запроса на вытягивание до succeeded публикации состояния. Pr можно пометить как исключение из политики, разместив состояние notApplicable, которое приведет к удалению требования политики.

2. Условный — политика не применяется, пока первое состояние не будет размещено в запросе на вытягивание.

Вместе эти параметры можно использовать для создания набора динамических политик. Политика оркестрации верхнего уровня может применяться по умолчанию при оценке pr для применимых политик. Затем, поскольку для применения дополнительных условных политик (возможно, на основе конкретных выходных данных сборки) можно опубликовать состояние, чтобы сделать их обязательными. Эта политика оркестрации может быть помечена после завершения оценки или может быть помечена succeeded notApplicable , чтобы указать на pr, что политика не применяется.

Настраиваемые действия

Помимо предопределенных событий перехватчика служб, которые могут активировать службу для обновления состояния pr, можно расширить меню состояния с помощью расширений Azure DevOps Services, чтобы предоставить пользователю действия триггера. Например, если состояние соответствует тестовой запуску, который может быть перезапущен конечным пользователем, можно иметь элемент меню "Перезапустить " в меню состояния, которое активирует тесты для выполнения. Чтобы добавить меню состояния, необходимо использовать модель вклада. Дополнительные сведения см. в примере расширения Azure DevOps.

Следующие шаги

Дополнительные сведения об API состояния PR и проверка руководствах.

• Создание сервера состояния запроса на вытягивание с помощью Node.js
• Использование Функций Azure для создания пользовательских политик ветвей
• Настройка политики ветвей для внешней службы