0

We have an Azure pipeline building a static site. When there is a change in a content repository the site needs to be rebuilt. For that, we're using webhooks and Azure DevOps API. The request to queue the build is very simple and is illustrated for example here.

What I don't like about this is that int the build listing it says "Manually triggered for person XY", where the person XY is the one who generated the credentials used in the API request. It seems quite confusing because any API request seems strange to be labeled as "manually requested". What would be the best way how to achieve more semantically correct message?

I've found there is a reason property which can be sent in the request. But none of the values seems to represent what I want and some of them do not work (probably need additional properties and there is no documentation for that).

mivra
  • 1,310
  • 16
  • 30

2 Answers2

1

Based on my test, when you use the Rest API to queue a build and set the build reason, the reason could be shown in the Build(except：batchedCI and buildCompletion).

Here is the Rest API example:

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

Request Body:

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

"reason":"pullRequest"

}

The value : checkInShelveset individualCI pullRequest schedule could show their own names.

enter image description here

The value: manual and none could show manually trigger.

The other value(e.g. All, userCreated) will show Other Build Reason.

For the value: batchedCI and buildCompletion.

BatchedCI: Continuous integration (CI) triggered by a Git push or a TFVC check-in, and the Batch changes was selected.

This means that batch changes are required to achieve this trigger. So it doesn't support to queue build in Rest API .

buildCompletion: you could refer to this ticket This reason doesn't support in Rest API-queue Build.

Note: If you enter a custom value or misspelling, it will always display manual trigger.

Kevin Lu-MSFT
  • 20,786
  • 3
  • 19
  • 28
  • Thanks @Kevin-Lu-MSFT. This is a great summary, marking it as accepted. Any insights on whether the reason value (especially "all") may cause some unwanted side effects? – mivra Jul 20 '20 at 12:11
0

In the end, I went with all value and also overriding the person via requestedFor property. This leads to the message "Other build reason", which seems usable to me.

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

}

However, I'm not sure if there aren't any unwanted consequences of this "All reasons" value.

mivra
  • 1,310
  • 16
  • 30