在 Azure Devops 的拉取请求中显示验收标准
Show acceptance criteria in pull requests in Azure Devops
在 Azure Devops 中审查 PR 时，如果 task/story 的 接受标准 会显示在描述中（例如，在提交消息之前），那将是理想的.这是为了确保所有必需的功能都已实现，并且所有边缘情况都已被考虑在内。您似乎需要手动打开工作项才能找到此附加信息。
AC可以自动显示在PR的描述中吗？
这是可能的，但不是直接的:)
我想到的一个选项是通过分支机构政策分配一个可选的审阅者：
您可以转到项目设置 -> 存储库 -> 自动包含审阅者。你可以使用例如一个服务帐户，它没有真实身份（或诚实的任何其他帐户），并为为特定分支创建的每个 PR 分配它。当您将此类分配设置为可选时，您将能够在不接受该帐户的情况下完成 PR，并且在 PR 的提要中将添加描述，这可能是您的 AC。
这当然是假设您拥有通用 AC 的情况。如果你想根据任务 AC 添加 AC，你将利用 Azure DevOps 的 REST API 并在每次创建 PR 时添加它们。需要一些额外的编程，但它仍然可行。
拥有包含详细信息的拉取请求当然可以改善审阅者的体验，并且由于 PR 与提交历史相关联，因此 PR 的描述也可以帮助个人审阅历史。虽然没有 built-in 功能可以将工作项的详细信息复制到 PR 的描述中，但有几个选项。
拉取请求策略选项
- 需要 linked 工作项：策略确实支持要求工作项 linked 到 PR 的选项。这些确实扩展为描述，并且很容易超link完成任务。
- 需要评论解决：您可以在PR中添加评论，要求作者提供更多细节。在他们满足该要求之前，PR 不会关闭。
改进拉取请求描述的选项
- 拉取请求模板：支持使用创建 PR 之前出现的默认文本填充 PR。这只是一个具有特殊命名约定的降价文件，因此没有添加自动化的选项，但它的目的是让您在 PR 被接受之前与 PR 作者沟通您想要什么。 http://www.bryancook.net/2020/06/using-templates-to-improve-pull.html?m=1
- 提交信息：鼓励您的团队提供更好的提交信息。如果他们在消息中包含 work-item 号码 (#1234)，它将 auto-expand 到 work-item 描述，link 到 work-item 自动发送到 PR .您甚至可以包含更改工作项状态的语法（已解决：#1234）
- Markdown: PR描述可以写成markdown格式，这样PR作者就可以为自己的改动提供一个很好的案例，包括图片、表格等
PR 可扩展性选项
老实说，为了完整起见，我将这些包括在这里。这是很多代码和令人头疼的开发人员卫生问题。
- 自定义构建：您可以编写一个在每次代码更改时运行的构建定义，以检查构建的细节，如果某些细节不存在则失败。 high-level PR（PR ID）的详细信息可作为 environment variables to the build (Build.Reason, Build.SourceBranch), so you could use the REST API to fetch the PR information 获得并执行一些自定义检查，例如是否存在您期望的某些关键字或格式。然后，您可以将此构建定义关联为 PR 策略中的必需构建。
- 状态API：与上面类似的方法，创建一个构建来查找您的构建定义插入到 PR 描述中的某些关键字的存在。如果找不到此文本，请使用 API 获取 work-item(s) 的详细信息（如果 linked 到 PR），更新 PR 和 post给 PR 的状态消息。将状态检查的定义添加到 PR 策略中。
- Webhook + Status API：与这两种方法类似，您可以设置一个自定义 webhook，它可以在任何时候调用自定义端点，而不是触发构建创建或更新。自定义端点将状态消息发布回 PR，并且 PR 策略设置为强制执行。 This article outlines how to create a Azure Function to perform a custom policy.
作为审阅者要记住的关键一点是，在满足您的需求之前，您不必完成 PR。
Can the AC be displayed automatically in the PR's description?
简短的回答是是。
首先，我需要声明目前没有现成的方法可以满足您的需求。在 10 月 1 日刚刚发布的最新 sprint-176-update 中，MS 引入了一项新功能，合并 pull request 时自定义工作项状态。但它仅适用于工作项 state 不适用于其他字段。
要解决此请求，我们可以在目标分支上添加 构建验证 以调用 REST API Pull Requests - Update 使用 task/story.
的验收标准更新描述
PATCH https://dev.azure.com/{organization}/{project}/_apis/git/repositories/{repositoryId}/pullrequests/{pullRequestId}?api-version=6.0
从上面的 REST API URL，我们可以知道如果我们想使用 REST API Pull Requests - Update，我们需要提供 pullRequestId。
在predefined variables中，有一个变量System.PullRequest.PullRequestId，我们可以用它来得到pullRequestId。
获得 pullRequestId 后，我们可以使用另一个 REST API Pull Request Work Items - List 来获得与拉取请求关联的工作项：
GET https://dev.azure.com/{organization}/{project}/_apis/git/repositories/{repositoryId}/pullRequests/{pullRequestId}/workitems?api-version=6.0
我们可以获得工作项 ID：
现在，我们可以使用 Work Items - Get Work Item 来获取 验收标准的值 :
最后，我们可以使用 REST API 拉取请求 - 使用 task/story.
的验收标准更新描述
下面是我的测试 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
这是测试结果：
在 Azure Devops 中审查 PR 时，如果 task/story 的 接受标准 会显示在描述中（例如，在提交消息之前），那将是理想的.这是为了确保所有必需的功能都已实现，并且所有边缘情况都已被考虑在内。您似乎需要手动打开工作项才能找到此附加信息。
AC可以自动显示在PR的描述中吗？
这是可能的，但不是直接的:)
我想到的一个选项是通过分支机构政策分配一个可选的审阅者：
您可以转到项目设置 -> 存储库 -> 自动包含审阅者。你可以使用例如一个服务帐户，它没有真实身份（或诚实的任何其他帐户），并为为特定分支创建的每个 PR 分配它。当您将此类分配设置为可选时，您将能够在不接受该帐户的情况下完成 PR，并且在 PR 的提要中将添加描述，这可能是您的 AC。
这当然是假设您拥有通用 AC 的情况。如果你想根据任务 AC 添加 AC，你将利用 Azure DevOps 的 REST API 并在每次创建 PR 时添加它们。需要一些额外的编程，但它仍然可行。
拥有包含详细信息的拉取请求当然可以改善审阅者的体验，并且由于 PR 与提交历史相关联，因此 PR 的描述也可以帮助个人审阅历史。虽然没有 built-in 功能可以将工作项的详细信息复制到 PR 的描述中，但有几个选项。
拉取请求策略选项
- 需要 linked 工作项：策略确实支持要求工作项 linked 到 PR 的选项。这些确实扩展为描述，并且很容易超link完成任务。
- 需要评论解决：您可以在PR中添加评论，要求作者提供更多细节。在他们满足该要求之前，PR 不会关闭。
改进拉取请求描述的选项
- 拉取请求模板：支持使用创建 PR 之前出现的默认文本填充 PR。这只是一个具有特殊命名约定的降价文件，因此没有添加自动化的选项，但它的目的是让您在 PR 被接受之前与 PR 作者沟通您想要什么。 http://www.bryancook.net/2020/06/using-templates-to-improve-pull.html?m=1
- 提交信息：鼓励您的团队提供更好的提交信息。如果他们在消息中包含 work-item 号码 (#1234)，它将 auto-expand 到 work-item 描述，link 到 work-item 自动发送到 PR .您甚至可以包含更改工作项状态的语法（已解决：#1234）
- Markdown: PR描述可以写成markdown格式，这样PR作者就可以为自己的改动提供一个很好的案例，包括图片、表格等
PR 可扩展性选项
老实说，为了完整起见，我将这些包括在这里。这是很多代码和令人头疼的开发人员卫生问题。
- 自定义构建：您可以编写一个在每次代码更改时运行的构建定义，以检查构建的细节，如果某些细节不存在则失败。 high-level PR（PR ID）的详细信息可作为 environment variables to the build (Build.Reason, Build.SourceBranch), so you could use the REST API to fetch the PR information 获得并执行一些自定义检查，例如是否存在您期望的某些关键字或格式。然后，您可以将此构建定义关联为 PR 策略中的必需构建。
- 状态API：与上面类似的方法，创建一个构建来查找您的构建定义插入到 PR 描述中的某些关键字的存在。如果找不到此文本，请使用 API 获取 work-item(s) 的详细信息（如果 linked 到 PR），更新 PR 和 post给 PR 的状态消息。将状态检查的定义添加到 PR 策略中。
- Webhook + Status API：与这两种方法类似，您可以设置一个自定义 webhook，它可以在任何时候调用自定义端点，而不是触发构建创建或更新。自定义端点将状态消息发布回 PR，并且 PR 策略设置为强制执行。 This article outlines how to create a Azure Function to perform a custom policy.
作为审阅者要记住的关键一点是，在满足您的需求之前，您不必完成 PR。
Can the AC be displayed automatically in the PR's description?
简短的回答是是。
首先，我需要声明目前没有现成的方法可以满足您的需求。在 10 月 1 日刚刚发布的最新 sprint-176-update 中，MS 引入了一项新功能，合并 pull request 时自定义工作项状态。但它仅适用于工作项 state 不适用于其他字段。
要解决此请求，我们可以在目标分支上添加 构建验证 以调用 REST API Pull Requests - Update 使用 task/story.
的验收标准更新描述PATCH https://dev.azure.com/{organization}/{project}/_apis/git/repositories/{repositoryId}/pullrequests/{pullRequestId}?api-version=6.0
从上面的 REST API URL，我们可以知道如果我们想使用 REST API Pull Requests - Update，我们需要提供 pullRequestId。
在predefined variables中，有一个变量System.PullRequest.PullRequestId，我们可以用它来得到pullRequestId。
获得 pullRequestId 后，我们可以使用另一个 REST API Pull Request Work Items - List 来获得与拉取请求关联的工作项：
GET https://dev.azure.com/{organization}/{project}/_apis/git/repositories/{repositoryId}/pullRequests/{pullRequestId}/workitems?api-version=6.0
我们可以获得工作项 ID：
现在，我们可以使用 Work Items - Get Work Item 来获取 验收标准的值 :
最后，我们可以使用 REST API 拉取请求 - 使用 task/story.
的验收标准更新描述下面是我的测试 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
这是测试结果：