Geekly articles weekly

在VSTS中启用可扩展的请求请求策略以支持开发过程

通常，作为“拉取请求”检查的一部分，除了代码检查本身之外，还需要执行一组常规检查。 一些检查可能与PR的设计有关。 其他-检查构成变更采用过程基础的相关条件。
如果常规检查不是自动进行的，那么人们可能会开始忘记或规避它们。 因为例行很无聊。


Visual Studio Team Services为处理请求请求提供了相当方便的基础结构。 这包括自定义合并构建策略，审阅者的任命，接受更改的合并规则。 所有这些都得到了方便的用于讨论和注释代码的系统的补充。


扩展“拉取请求”过程最强大的工具是外部插件策略。


我们将讨论它们的创建和使用（并查看代码）


可扩展的拉取请求状态


PR状态是在上下文中定义的标志。 上下文-上下文名称和“类型”的唯一组合。 该类型通常是每个操纵状态的应用程序之一。


例如：


状态1：类型=“ my-policy”，名称=“ check-1”
状态2：类型=“ my-policy”，名称=“ check-2”


状态采用预定义值之一。 为了支持该过程，我们将对两个感兴趣：成功和失败。


设置早午餐策略时可以使用状态：所选标志必须具有成功的状态才能接受PR。 以相同的方式，实施了内置策略来检查驱动程序的数量，附加票证的存在等。


转到编辑分支策略。 添加外交政策。
早午餐政策


如果状态至少已设置一次，则在下拉菜单中将可用该状态。
在底部，您可以指定状态的标题，以及如何在拉取请求完成框中显示状态。


根据需要添加外交政策


添加的状态将显示在检查块中的请求请求页面上：

如果状态未用作策略，则其值将显示在“状态”部分的页面上。 如果将状态指定为策略，则它将在块顶部可见。


程序状态管理


可以使用REST API以编程方式处理PR状态。 因此，可以实施其他PR检查，并将其结果直接转换为进行更改的过程。


新的状态值由Create方法添加。 除了结果和上下文，还必须传达用户看到的文本。 您可以选择传递URL：在这种情况下，PR表单上的状态标签将成为链接，并且用户将能够转到包含状态详细信息的页面。


方法调用将导致创建新的PR状态记录。 在一个上下文中，最后添加的状态值被认为是活动的。 早期状态条目在UI中不可见，但是可以使用List方法获得它们。


对于上图中状态的状态，拉取请求的真实状态列表可以如下：


{ "value": [ { "id": 1, "state": "failed", "description": "PR title format", "context": "@{name=check-title; genre=my-pr-policy}", "creationDate": "2018-11-06T18:35:57.0324172Z", "updatedDate": "2018-11-06T18:35:57.0324172Z", "createdBy": "Masked value", "targetUrl": null }, { "id": 2, "state": "failed", "description": "Build for last update", "context": "@{name=check-build; genre=my-pr-policy}", "creationDate": "2018-11-06T18:35:57.5167963Z", "updatedDate": "2018-11-06T18:35:57.5167963Z", "createdBy": "Masked value", "targetUrl": null }, { "id": 3, "state": "succeeded", "description": "No offset from develop", "context": "@{name=check-offset; genre=my-pr-policy}", "creationDate": "2018-11-06T18:35:57.782379Z", "updatedDate": "2018-11-06T18:35:57.782379Z", "createdBy": "Masked value", "targetUrl": null }, { "id": 4, "state": "succeeded", "description": "PR title format", "context": "@{name=check-title; genre=my-pr-policy}", "creationDate": "2018-11-06T18:46:37.2627154Z", "updatedDate": "2018-11-06T18:46:37.2627154Z", "createdBy": "Masked value", "targetUrl": null }, { "id": 5, "state": "succeeded", "description": "Build for last update", "context": "@{name=check-build; genre=my-pr-policy}", "creationDate": "2018-11-06T18:51:33.7920543Z", "updatedDate": "2018-11-06T18:51:33.7920543Z", "createdBy": "Masked value", "targetUrl": null }, { "id": 6, "state": "failed", "description": "PR title format", "context": "@{name=check-title; genre=my-pr-policy}", "creationDate": "2018-11-06T18:53:44.3075889Z", "updatedDate": "2018-11-06T18:53:44.3075889Z", "createdBy": "Masked value", "targetUrl": null }, { "id": 7, "state": "failed", "description": "Title format is not correct", "context": "@{name=check-title; genre=my-pr-policy}", "creationDate": "2018-11-06T19:26:11.3019433Z", "updatedDate": "2018-11-06T19:26:11.3019433Z", "createdBy": "Masked value", "targetUrl": null } ], "count": 7 }

查看当前状态列表后，可以按列表中的索引更新所选状态。 为此，请使用Update方法。


最后，可以使用Delete方法删除状态记录。


PR状态更改的历史记录对于进一步分析很有用。 因此，我们使用以下更改状态的方法：


  • 查找相同上​​下文的最新状态记录
  • 如果她具有与我们要添加的结果值，描述和链接相同的结果，那么我们什么也不做
  • 否则，添加一个新的状态记录。
    这使您可以保留更改历史记录，而不会夸大更改。

 function Set-PullRequestStatus { param( [Parameter (Mandatory = $true)] [string] $pullRequestId, [Parameter (Mandatory = $true)] [string] $state, [Parameter (Mandatory = $true)] [string] $description, [Parameter (Mandatory = $true)] [string] $contextName, [Parameter (Mandatory = $false)] [string] $contextGenre, [Parameter (Mandatory = $false)] [string] $targetUrl, [Parameter (Mandatory = $true)] [object] $context ) $b = @{ state = $state; description = $description; context = @{ name = $contextName; genre = $contextGenre; }; targetUrl = $targetUrl; } $body = ConvertTo-Json $b # # Get current list of statuses # $endpoint = (Get-ProjectBaseURL) + "/_apis/git/repositories/{repositoryId}/pullRequests/{pullRequestId}/statuses?api-version=4.1-preview.1" $res = Get-AzureRequestReqults -URI $endpoint -context ($context + @{pullRequestId = $pullRequestId}) # # Try to find a status for a given context genre and name. Start looking from the last one. If found - check if it has same values. # $i = $res.count $foundSameStatus = $false while ($i -GT 0) { $r = $res.value[$i-1] if (($r.context.name -EQ $contextName) -AND ($r.context.genre -EQ $contextGenre)) { $foundSameStatus = ($r.state -EQ $state) -AND ($r.description -EQ $description) -AND ($r.targetUrl -EQ $targetUrl) break } $i-- } $res = $r # # If same status / values was not found - add new record. # if (-not $foundSameStatus) { $endpoint = (Get-ProjectBaseURL) + "/_apis/git/repositories/{repositoryId}/pullRequests/{pullRequestId}/statuses?api-version=4.1-preview.1" $res = Get-AzureRequestReqults -URI $endpoint -context ($context + @{pullRequestId = $pullRequestId}) -method POST -query $body } return @{status = $res; status_changed = $(-not $foundSameStatus)} }

实际应用


我们采用了一种相当保守的方法来接受对集成分支的更改。 我们尝试在功能分支上测试最大的更改。


以下是我们在PR状态的帮助下解决的一些任务，这是自定义策略的一部分：


  1. 所有PR必须以相同的样式装饰。 因此，创建的第一个控件是PR标头的设计。 我们对照正则表达式检查它。
  2. PR分支不应滞后于注入分支的分支（进行积分）。
  3. 如果在PR框架内更改了数据库项目文件，则还必须存在自动测试文件。
  4. 分支的最后一次更改已成功组装。
  5. 该组件已成功泵送到测试台，并通过了自动测试。

列出的条件可以手动检查。 我们以前做过。 但这是一个例行程序，已由自动化过程代替。 现在，我们可以补充和更改检查集-它将始终集成到流程中，并始终执行。


在PR页面上，还有大量其他政策-对所有人透明，并且始终可见。 他们不再需要被提醒。
此外，对于未通过验证的策略，我们将显示指向Wiki页面的链接，其中包含策略和预期操作的描述。


政策执行的技术实施


当前，策略逻辑以powershell脚本的形式实现。 由于高级cmdlet和良好的对象数据模型，因此脚本代码非常紧凑。 能够逐步运行脚本并修改变量的功能-极大地简化了开发和调试过程。


顺便说一句，在Powershell核心发布之后，脚本可以在其他平台上运行（在MacOS上进行了测试）。


在VSTS的特殊版本中，按大约每两小时一次的时间表运行脚本。 也许我们会开始更频繁地浏览Sheduler。


当然，与以Azure函数的形式实现相同功能并通过Web挂钩将其连接到VSTS相比，此方法的响应速度明显慢得多。 但是对我们而言，实施检查并查看其在流程中的工作方式（MVP）更为重要。 检查的效率并不重要。 这将是下一步。


可以在GitHub上的存储库中找到用于VSTS REST API的库的实现（用于检查），以及一个实现其中某些策略的小示例。 我希望有人会觉得有用。

Source: https://habr.com/ru/post/zh-CN428660/

More articles:


All Articles