如何通过API以不报告手动触发的方式触发Azure管道

Question

我们有一个Azure管道来构建静态站点。当内容存储库中发生更改时，需要重建站点。为此，我们使用了webhooks和Azure DevOps API。排队构建的请求非常简单，例如here所示。

我对此不满意的是int生成的清单上显示“手动为人员XY触发”，其中人员XY是生成API请求中使用的凭据的人。这似乎很令人困惑，因为任何API请求似乎都被标记为“手动请求”，这很奇怪。如何获得语义上更正确的消息的最佳方法是什么？

我发现有一个reason property可以在请求中发送。但是这些值似乎都不能代表我想要的值，并且其中一些值不起作用（可能需要其他属性，因此没有相关文档）。

Answer 1

根据我的测试，当您使用Rest API对构建进行排队并设置构建原因时，原因可能会显示在Build中（batchedCI和buildCompletion除外）。

这是Rest API示例：

Post https://dev.azure.com/Organization/Project/_apis/build/builds?api-version=4.1

请求正文：

{ 
"definition": {
    "id": 372 
},

"reason":"pullRequest"

}

值：checkInShelveset individualCI pullRequest schedule可以显示自己的名称。

值manual和none可以手动显示。

其他值（例如，全部，userCreated）将显示Other Build Reason。

对于值：batchedCI和buildCompletion。

BatchedCI：通过Git推送或TFVC签入触发的持续集成（CI），并且选择了Batch更改。

这意味着需要批量更改才能实现此触发。因此，它不支持在Rest API中对构建进行排队。

buildCompletion：您可以参考this ticket，此原因在Rest API队列构建中不支持。

注意：如果您输入自定义值或拼写错误，它将始终显示手动触发。

Answer 2

最后，我使用了all的值，并通过requestedFor属性覆盖了这个人。这导致出现消息“其他构建原因”，对我来说似乎可用。

{ 
"definition": {
    "id": 17
},
"reason":"all",
"requestedFor": {
    "id": "4f9ff423-0e0d-4bfb-9f6b-e76d2e9cd3ae"
}

}

但是，我不确定此“所有原因”值是否不会有任何不良后果。