I would like to start a Azure Pipelines build through the REST API. There is an API for queuing builds but I couldn't find a way to define variables.
The accepted answer does not really answers the question when you need to set a value at queue time.
The solution is actually pretty simple you just have to add a parameters field to the json payload. The content should be a json string (not directly an object) containing the parameters
Ex :
{
"parameters": "{\"ReleaseNumber\": \"1.0.50\", \"AnotherParameter\": \"a value\"}",
"definition": {
"id": 2
}
}
EDIT : This feature is now properly documented as an optional stringified dictionary. See https://www.visualstudio.com/fr-fr/docs/integrate/api/build/builds#queue-a-build
Variables are included in definitions, you can update your build definition to set the variables via build-definition api first and then queue the build.
Following is the variable section get via build-definition api:
"variables": {
"system.debug": {
"value": "false",
"allowOverride": true
},
"BuildConfiguration": {
"value": "release",
"allowOverride": true
},
"BuildPlatform": {
"value": "any cpu",
"allowOverride": true
}
},
For anyone having problems with this (I did), there is a difference in APIs used since the accepted answer (which to me didn't work at all). But following Cyprien Autexier's advice, I took a look under the hood (Firefox Dev Tools) and I noticed the portal does not use the Builds API anymore. It uses the Pipelines one (https://learn.microsoft.com/en-us/rest/api/azure/devops/pipelines/runs/run-pipeline?view=azure-devops-rest-6.1). With this, worked flawlessly.
For anyone looking this, I was able to make it work with 'templateParameters', which allow you to send an Object instead of a String on version 7.1.
Method: POST
URL: https://dev.azure.com/{organization}/{project}/_apis/build/builds?api-version=7.1-preview.7
Body: JSON example:
{
"sourceBranch":"Development",
"definition": {
"id": 5
}
"templateParameters": {
"PARAMETER1": "value1",
"parameter2": "valuex"
}
}
Docs: https://learn.microsoft.com/en-us/rest/api/azure/devops/build/builds/queue?view=azure-devops-rest-7.1
Seems it works with 5.1. All you need to do is define the variables you pass in as parameters within the pipeline variables and ensure the checkbox "Settable at queue time" is checked. If you have same variable in any library make sure you remove those references as library variables are seen to override those set via API.
Note I use Azure Devops Server 2019
API: https://learn.microsoft.com/en-us/rest/api/azure/devops/build/builds/queue?view=azure-devops-rest-5.1
Navigating to set variables: Edit the YAML pipeline -->click on the 3 dots near "Run" button --> Variables --> Variables TAB
Hope it helps someone
Related
Requirements: We would like to create a Variable Group (along with some variables) in a given Project.
Option1: We are able to create a new Variable Group successfully
when we create a request via PostMan using PAT Token which has FULL access.
Option2: Our end goal is to invoke the ADO Rest API in the Web App which uses
OAuth. When the end user logs in and make a call (pls see the input
details below) we are getting '401 Un Authorized - The user is not authorized to access this resource.' error. The Web App's application has the Variable Groups manage scope as shown below.
TroubleShooting: As part of troubleshooting, for Option1 which uses PAT (with full access) in Postman, we have updated the permissions of the PAT to just have Create, Read and Manage Var Groups as shown below.
Now, even the Option1 is not working after making the PAT to have Custom Defined access.
Are we missing something?
Postman Details:
URL: https://dev.azure.com/myorgname/_apis/distributedtask/variablegroups?api-version=6.0-preview.2
Verb: Post
Headers: Authorization: Basic
Body:
{
"name": "This is ignored",
"description": "This is ignored",
"type": "Vsts",
"variables": {
"BuildConfiguration": {
"value": "Release"
}
},
"variableGroupProjectReferences": [
{
"name": "VarGroup",
"description": "The variable group to store the information about the variables using in the Pipeline",
"projectReference": {
"id": "#ProjectId#",
"name": "#ProjectName#"
}
}
]
}
I can also reproduce your issue with option 1, not only Read, create, & manage for Variable Groups, even I select all the scopes via Custom defined, it still does not work.
According to this doc - https://learn.microsoft.com/en-us/azure/devops/organizations/accounts/manage-pats-with-policies-for-administrators?view=azure-devops#restrict-creation-of-full-scoped-pats
Some of our public APIs are currently unassociated with a PAT scope, and can therefore only be used with “full-scoped” PATs. Because of this, restricting the creation of full-scoped PATs might block some workflows. We're working to identify and document the affected APIs and eventually associate them with the appropriate scope. For now, these workflows can be unblocked by using the allow list.
I believe this should be the reason for this issue, there may be some additional permissions to create variable groups. For option 2, there may be a similar cause.
So in this case, you may need to use the Full access PAT temporarily, as mentioned in the doc We're working to identify and document the affected APIs and eventually associate them with the appropriate scope.
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).
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.
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.
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.
I'm looking to incorporate Test-AzureRmResourceGroupDeployment into a build pipeline so I know before deployment that the template / parameters has got any major problems.
However I'm finding if I used nested deployments it provides no validation to the nested deployment whatsoever, I can have a bad templateLink -> uri with incorrect variables even in the URI and it's still validating as successful.
I have tried with a local template, a template uri, with/without hashed parameters and parameters file just in case.
I assume underneath the AzureRM powershell is using the Resource Manager API, it doesn't hint to what the validate actually does with nested templates: https://learn.microsoft.com/en-us/rest/api/resources/deployments/validate
Anything I've missed? Any suggestions on how to validate the entire template, do I need to parse the nested templates and some how re-construct the parameters from json and do the sub-deployments by hand (which would be a shame)?
Reading a forum post from a Microsoft Employee in the Resource Manager team (a private forum so unfortunately cannot provide a link), it appears Test-AzureRmResourceGroupDeployment does "template expansion" which as 4c74356b41 has also kindly pointed out - surely the nested template validation should work...
So further experimentation has led to finding a limitation in the validation, see below for an example. If there is a variable missing entirely in a nested deployment it doesn't appear to be picked up as a validation warning in the parent template, and also appears to interfere with the template expansion leading to the nested template to be ignored also.
If "parameters": { "missing" : "[variables('PURPOSEFULLY_MISSING')]" } is removed then the template is validated as normal and the nested template also.
Snippet of the overall template for just the nested resources:
"resources": [
{
"name": "[variables('deploymentName')]",
"type": "Microsoft.Resources/deployments",
"apiVersion": "2018-05-01",
"properties": {
"mode": "Incremental",
"templateLink": {
"uri": "[variables('deploymentUri')]",
"contentVersion": "1.0.0.0"
},
"parameters": { "missing" : "[variables('PURPOSEFULLY_MISSING')]" }
}
}
],
that is not true, it will validate nested deployment even if you gate it with condition: false, so you are doing something wrong, we would need to look at the template and how you are calling the cmdlet to understand whats going on
as to the validation: there is no real way to validate the deployment works (test-azurermresourcegroupdeployment is just garbage, extremely low value). the only way to validate it - deploy it.
I have noticed that upon saving dataset definition in data factory via the azure portal that
"published": false
Appears in the definition, I have seen dataset's work fine with published false. But also seen some seemingly only start working with published: true, however that might of been a coincidence.
I've been unable to find any documentation for this property.
{
"name": "DataLakeDummyXmlInput",
"properties": {
"published": false,
"type": "AzureDataLakeStore",
This property is currently classified as "legacy" as described by a Microsoft employee here:
...this is a legacy element in our object model.
The link also mentions the possibility of "lighting it up as a future feature" which translates as it may come in to use in the future. For now, don't worry about it.
The Watson Dialog Service on IBM Bluemix allows to create profile variables and to pass values to them. In the examples these variables always seem to have the type "TEXT" (see "myVariable" below). Are there any other types available? How would I pass a JSON object and how would I access specific values inside a dialog?
<variables>
<var_folder name="Home">
<var name="myVariable" type="TEXT"/>
</var_folder>
</variables>
I talked with the service team, and the recommendation is to use the new Watson Conversation service as it is actually possible to pass an array of name:value pairs. Below is a sample that the team came up with on the fly. Hopefully it's helpful.
Sample:
{
"client_id": 4435,
"name_values": [
{
"name": "string",
"value": "string"
}
]
}
For example, if you want to post to a context variable named JSON_object, the PUT context payload would be:
{
"client_id": 4435,
"name_values": [
{
"name": "JSON_object",
"value": "{"sample":"data"}"
}
]
}
HOWEVER, they highly recommend converting the JSON to flat XML before posting as context, since dialog has much more versatility to parse XML, using {variable_name.xmlElementName}.
More info found on the API explorer - https://watson-api-explorer.mybluemix.net/apis/dialog-v1#!/Profile/setProfile under PUT CONTEXT method.
Best to go to the documentation.
variables can be objects - consisting of many vars
http://www.ibm.com/watson/developercloud/doc/dialog/reference_elements.shtml#reference_variables
vars can be of types
http://www.ibm.com/watson/developercloud/doc/dialog/reference_elements.shtml#reference_var