При проверке PR в Azure Devops было бы идеально, если бы критерии приемлемости задачи / истории отображались в описании (например, перед сообщениями о фиксации). Это делается для того, чтобы убедиться, что все необходимые функциональные возможности были реализованы и все крайние случаи были приняты во внимание. Похоже, вам нужно вручную открыть рабочий элемент, чтобы найти эту дополнительную информацию.

Могут ли критерии приемлемости автоматически отображаться в описании PR?

Может ли AC автоматически отображаться в описании PR?

Короткий ответ — да.

Во-первых, я должен заявить, что на данный момент нет готового способа удовлетворить ваши потребности. В последнем обновлении sprint-176, выпущенном 01 октября, MS представила новую функцию «Настройка состояния рабочего элемента при объединении запросов на извлечение». Но это только для состояния рабочего элемента, а не для других полей.

Чтобы разрешить этот запрос, мы могли бы добавить проверку сборки в целевую ветку для вызова запросов на извлечение REST API — Обновление для обновления описания критериями приемлемости задачи / истории.

 PATCH https://dev.azure.com/{organization}/{project}/_apis/git/repositories/{repositoryId}/pullrequests/{pullRequestId}?api-version=6.0
  

Из приведенного выше URL-адреса REST API мы могли бы узнать, что если мы хотим использовать запросы на извлечение REST API — обновление, нам нужно предоставить pullRequestId .

В предопределенных переменных есть переменная System.PullRequest.PullRequestId , которую мы могли бы использовать для ее получения pullRequestId .

После того, как мы получим pullRequestId , мы могли бы использовать другой список рабочих элементов запроса запроса REST API, чтобы получить рабочие элементы, связанные с запросом на извлечение:

 GET https://dev.azure.com/{organization}/{project}/_apis/git/repositories/{repositoryId}/pullRequests/{pullRequestId}/workitems?api-version=6.0
  

Мы могли бы получить идентификатор workitems:

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

Наконец, мы могли бы использовать запросы на извлечение REST API — Обновление с обновлением описания с критериями приемлемости задачи / истории.

Ниже приведены мои тестовые сценарии powershell:

 $PullRequestId = $Env:System_PullRequest_PullRequestId

Write-Host "Current PullRequestId is $PullRequestId"

$url = "https://dev.azure.com/<YourOrganizationName>/<YourProjectName>/_apis/git/repositories/<YourRepoId>/pullRequests/$($PullRequestId)/workitems?api-version=6.0"
$PullRequestWorkItems= Invoke-RestMethod -Uri $url -Headers @{   
 Authorization = "Bearer $env:SYSTEM_ACCESSTOKEN"
} -Method Get

$WorkItemId= $PullRequestWorkItems.value.id

Write-Host This is WorkItems Id: $WorkItemId

$Testurl = "https://dev.azure.com/<YourOrganizationName>/<YourProjectName>/_apis/wit/workitems/$($WorkItemId)?api-version=6.0"
$WorkitemInfo= Invoke-RestMethod -Uri $Testurl -Headers @{   
 Authorization = "Bearer $env:SYSTEM_ACCESSTOKEN"
} -Method Get

$AcceptanceCriteria= $WorkitemInfo.fields.'Microsoft.VSTS.Common.AcceptanceCriteria'

Write-Host This is Acceptance Criteria info: $AcceptanceCriteria


$UpdatePRurl = "https://dev.azure.com/<YourOrganizationName>/<YourProjectName>/_apis/git/repositories/a<YourRepoId>/pullRequests/$($PullRequestId)?api-version=6.0"

$connectionToken="Your PAT"
$base64AuthInfo= [System.Convert]::ToBase64String([System.Text.Encoding]::ASCII.GetBytes(":$($connectionToken)"))


$headers = @{ Authorization = "Bearer $env:SYSTEM_ACCESSTOKEN" }

$body=@"
  {
    "description": "$($AcceptanceCriteria)"
  }
"@

Write-Host "$url"
$response= Invoke-RestMethod -Uri $UpdatePRurl -ContentType "application/json" -Body $body -headers @{authorization = "Basic $base64AuthInfo"} -Method PATCH  
  

Это результат теста:

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

Параметры политик запросов на извлечение

1. Требовать связанные рабочие элементы: политика поддерживает возможность требовать, чтобы рабочие элементы были связаны с PR. Они расширяются как описание и легко переходят по гиперссылке на задачу.
2. Требуется разрешение комментариев: вы можете добавить комментарий к PR, чтобы попросить автора предоставить более подробную информацию. PR не закроется, пока они не выполнят это требование.

Варианты улучшения описания запросов на извлечение

1. Шаблоны запросов на извлечение: поддерживается заполнение PR текстом по умолчанию, который появляется перед созданием PR. Это всего лишь файл markdown со специальным соглашением об именовании, поэтому нет возможности добавить автоматизацию, но его цель состоит в том, чтобы вы сообщили автору PR, что вы хотите, прежде чем PR будет принят. http://www.bryancook.net/2020/06/using-templates-to-improve-pull.html?m=1
2. Сообщения о фиксации: поощряйте свою команду предоставлять более качественные сообщения о фиксации. Если они включают номер рабочего элемента в сообщение (# 1234), оно автоматически расширится до описания рабочего элемента и автоматически свяжет рабочие элементы с PR. Вы даже можете включить синтаксис для изменения статуса рабочего элемента (решено: # 1234)
3. Markdown: описание PR может быть записано в формате markdown, что позволяет автору PR представить веские аргументы в пользу их изменения, включая изображения, таблицы и т. Д.

Варианты расширяемости PR

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

1. Пользовательская сборка: вы можете написать определение сборки, которое выполняется при каждом изменении кода для проверки деталей сборки и сбоя, если некоторые детали отсутствуют. Высокоуровневые сведения о PR (идентификатор PR) доступны в качестве переменных среды для сборки (Build.Причина, сборка.SourceBranch), чтобы вы могли использовать REST API для извлечения информации о PR и выполнения некоторых пользовательских проверок, таких как наличие определенных ключевых слов или ожидаемого формата. Затем вы можете связать это определение сборки как обязательную сборку в политике PR.
2. API состояния: аналогичный подход, описанный выше, создайте сборку, которая ищет наличие определенных ключевых слов, которые ваше определение сборки вставляет в описание PR. Если этот текст не найден, используйте API для получения сведений о рабочих элементах (элементах) (если они связаны с PR), обновите PR и отправьте сообщение о состоянии в PR. Добавьте определение проверки состояния, как требуется, в политику PR.
3. Webhook Status API: аналогично обоим подходам, вместо запуска сборки вы можете настроить пользовательский webhook, который вызывает пользовательскую конечную точку при каждом создании или обновлении PR. Пользовательская конечная точка отправляет сообщение о состоянии обратно в PR, и политика PR настроена на его принудительное выполнение. В этой статье описывается, как создать функцию Azure для выполнения пользовательской политики.

Как рецензенту важно помнить, что вам не нужно завершать PR, пока он не удовлетворит ваши потребности.

Это возможно, но это не напрямую 🙂

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

Вы можете перейти в Настройки проекта -> Репозитории -> Автоматически включаемые проверяющие. Вы могли бы использовать, например, учетную запись службы, у которой нет реального идентификатора (или, честно говоря, любой другой учетной записи), и назначить ее для каждого PR, созданного для определенной ветки. Если вы установите такое назначение как необязательное, вы сможете выполнить PR без принятия от этой учетной записи, а в ленту PR будет добавлено описание, которое может быть вашим AC.

Конечно, это предполагает, что у вас есть общие ACS. Если вы хотите добавить AC на основе задач AC, вам следует использовать REST API Azure DevOps и добавлять их каждый раз при создании PR. Требуется некоторое дополнительное программирование, но это все же выполнимо.