API POST not applied to branch with Azure DevOps Server (2019 Update 1) - azure-devops

I'm puzzled with the Azure DevOps API POST. I've successfully created a policy for "Minimum number of reviewers" but it's not being created against the branch I'm specifying. I've done this in Fiddler for the moment, here's my request (private values obfuscated):
POST http://our-tfs-server:8080/tfs/TheCollection/TheProject/_apis/policy/configurations?api-version=5.1 HTTP/1.1
Content-Type: application/json; charset=utf-8
Host: our-tfs-server:8080
Authorization: Basic MyBase64EncodedToken
{
"IsBlocking": true,
"IsEnabled": true,
"Settings": {
"MinimumApproverCount": 2,
"Scope": [
{
"RefName": "refs/heads/master",
"MatchKind": "exact",
"RepositoryId": "7718333c-044e-423a-baa1-45e6a1f0ff41"
}
]
},
"Type": {
"Id": "fa4e907d-c16b-4a4c-9dfa-4906e5d171dd"
}
}
and here's the response body:
{
"createdBy": {
"displayName": "Surname, Firstname",
"url": "http://our-tfs-server:8080/tfs/TheCollection/_apis/Identities/SomeString",
"_links": { "avatar": { "href": "http://our-tfs-server:8080/tfs/TheCollection/_apis/GraphProfile/MemberAvatars/win.SomeString" } },
"id": "7b40f8ab-a933-4b43-bdf8-bf0b179d28e6",
"uniqueName": "MyUsername",
"imageUrl": "http://our-tfs-server:8080/tfs/TheCollection/_api/_common/identityImage?id=SomeString",
"descriptor": "win.SomeOtherString"
},
"createdDate": "2020-01-23T02:09:34.4738854",
"isEnabled": true,
"isBlocking": true,
"isDeleted": false,
"settings": {
"minimumApproverCount": 2,
"creatorVoteCounts": false,
"allowDownvotes": false,
"resetOnSourcePush": false,
"scope": [ { "repositoryId": "7718333c-044e-423a-baa1-45e6a1f0ff41" } ]
},
"_links": {
"self": { "href": "http://our-tfs-server:8080/tfs/TheCollection/8b7e65ed-1136-4b0f-9780-de2a3860447a/_apis/policy/configurations/254" },
"policyType": { "href": "http://our-tfs-server:8080/tfs/TheCollection/8b7e65ed-1136-4b0f-9780-de2a3860447a/_apis/policy/types/fa4e907d-c16b-4a4c-9dfa-4906e5d171dd" }
},
"revision": 1,
"id": 254,
"url": "http://our-tfs-server:8080/tfs/TheCollection/8b7e65ed-1136-4b0f-9780-de2a3860447a/_apis/policy/configurations/254",
"type": {
"id": "fa4e907d-c16b-4a4c-9dfa-4906e5d171dd",
"url": "http://our-tfs-server:8080/tfs/TheCollection/8b7e65ed-1136-4b0f-9780-de2a3860447a/_apis/policy/types/fa4e907d-c16b-4a4c-9dfa-4906e5d171dd",
"displayName": "Minimum number of reviewers"
}
}
Note that "scope": [ { "repositoryId": "7718333c-044e-423a-baa1-45e6a1f0ff41" } ] only has the repositoryId.
In the UI on the policies for the branch the Minimum Number of reviewers option is not ticked and there's no version of the question at a full Repository level. If I call /_apis/policy/configurations then I see the new policy so it has been created. Perhaps this will now guard all branches with the policy, but we don't want it at a global level and given there's no tooling in the DevOps web ui for it I'm pretty sure it's not intended to be like that anyway.
So, is this an oversight in the way the API functions or is the branch to apply the policy configuration to set using another technique?

So...the answer lay in the capitalisation of property names on the json request body. Whilst json is not case sensitive and the request I was making was returning 200 and a valid body internally, the server was falling apart on the setting of the branch to apply the Policy Configuration to. NewtonSoft was serialising property names with capital letters at the beginning and I found that using lowercase fixed the original issue and the returned object which was created then had the refName and matchKind assigned and the MinimumNumberOfReviewers check box was ticked and the number set to 2. Why MS have failed to serialise only one or 2 properties is a little weird, at any rate I applied JsonSerializationSettings globally to avoid the need for adding JsonPropertyAttribute everywhere as well as ignoring null properties.

Related

For unsuccessful actions, there should not be outputs

I'm trying to test my workflow with HTTP request action... And when I select Status "Failure" - I can't add Output. But when I send a request without testing - I can see Output from the failed action (i.e. Status code, Body, Headers).
So, how can I test this one with Output parameters? Actually, I have to handle Status code in the subsequent actions.
My workflow seems like this:
{
"definition": {
"$schema": "https://schema.management.azure.com/providers/Microsoft.Logic/schemas/2016-06-01/workflowdefinition.json#",
"actions": {
"Bad": {
"inputs": {
"body": "Bad: #{outputs('HTTP')['statusCode']}",
"statusCode": 503
},
"kind": "http",
"runAfter": {
"HTTP": [
"TIMEDOUT",
"FAILED"
]
},
"type": "Response"
},
"HTTP": {
"inputs": {
"method": "GET",
"uri": "#{appsetting('externalServiceUrl')}/api/entities/"
},
"runAfter": {},
"type": "Http"
},
"Success": {
"inputs": {
"body": "Success",
"statusCode": 200
},
"kind": "http",
"runAfter": {
"HTTP": [
"Succeeded"
]
},
"type": "Response"
}
},
"contentVersion": "1.0.0.0",
"outputs": {},
"triggers": {
"manual": {
"inputs": {},
"kind": "Http",
"type": "Request"
}
}
},
"kind": "Stateful"
}
Actually, I have to handle Status code in the subsequent actions.
You just need to change the status as Succeeded and in Status Code when you scroll down you can find a bunch of status codes that you can set.
Additionally, To Handle Status Code further you can also use the Condition action of Control check if the HTTP connector has satisfied the conditions that we are looking for. Here is my logic app workflow.
So the Success executes for 200 and 202 status and rest all codes comes under bad action when executed.
My solution in Acceptance tests to test this workflow - I just mocked API using WireMock.
But lack of possibility to test with the default functionality (without Kludge) seems like a bug.

Azure DevOps KeyVault Linked Variable group "Value cannot be null. Parameter name: variableGroupParameters" - how do i fix this?

I have a need to automate the creation of KeyVault linked variable groups in ADO as part of a pipeline task. I can actually create the var groups after a bit of experimenting. However, using the az devops invoke method one is unable to specify the Azure Subscription and this has to be done manually, after the event - however when I do this in the web interface and attempt to save I get the error:
Value cannot be null. Parameter name: variableGroupParameters
This means any subsequent editing of the created KeyVault linked var group is pointless as it is unable to save it.
The JSON I am submitting is as follows:
{
"authorized": true,
"description": "$description",
"name": "$name",
"type": "AzureKeyVault",
"variableGroupProjectReferences": [{
"projectReference": {
"id": "$adoProjectID",
"name": "$ProjectName"
},
"name": "$name",
"description": "$description"
}],
"providerData": {
"serviceEndpointId": "$AdoSvcConnId",
"vault": "$KeyVaultNM"
},
"variables": {
"SOMETHINGSECRET": {
"isSecret": true,
"value": null,
"enabled": true,
"contentType": ""
},
"variables": {
"ANOTHERSECRET": {
"isSecret": true,
"value": null,
"enabled": true,
"contentType": ""
}
}
}
}
Where the $tokenized values are replaced during the powershell/az cli task
The command (which works but results in broken var group that can't be edited or saved) is as follows:
az devops invoke --http-method post --area distributedtask --resource variablegroups --in-file "vgroup_azure_rm.json" --encoding utf-8 --route-parameters project=$ProjectName --api-version 5.0-preview
Anyone have an insight in how to fix this please?
I was experiencing the same problem, and the message had nothing to do with the real issue.
I had the following variables:
"variables": {
"SECRET_1": {
"contentType": "",
"isSecret": true,
"value": "",
"expires": null,
"enabled": true
},
"SECRET_2": {
"contentType": "",
"isSecret": true,
"value": "",
"expires": null,
"enabled": true
},
"SECRET_3": {
"contentType": "",
"isSecret": true,
"value": "",
"expires": null,
"enabled": true
}
}
And was receiving the same error as you. I removed the expires property and the issue was solved! So my thinking is that the validation checks for any null value and returns the error you are receiving.
Try changing the property value to an empty string ("") instead of null and see whether that solves the problem.

Sonarqube REST API : What is the structure of "metrics" in "GET api/measures/component" WS

In the response example from the web api documentation, I can see metric "ncloc" should be like this in the JSON web response :
"measures": [
{
"metric": "ncloc",
"value": "114",
"periods": [
{
"index": 1,
"value": "3"
}
]
},
But it's not, there is no "periods" for this metric in my response :
"measures":[
{
"metric": "ncloc",
"value": "2943"
},
There are "periods" for some other metrics though, and in this case, there is no metric value, only a value for each period (and there are never multiple periods, only one corresponding to the "new code" period).
So here are my questions about this :
How can I know which structure to expect for a metric ? what would be the metric where "periods" would have a list of periods and not just one corresponding to "new code" ?
I don't think there are multiple periods. API documentation for my version (8.9) only states period, which probably stands for Leak Period as the New Code used to be called. I assume that general value is for overall value and period value is for the new code. Some measures may not make sense or be counted for overall or new code, so I would not make assumptions on whether there will be a metric value for the period or general.
Edit:
The following is the 8.9 documentation:
GET api/measures/component
SINCE 5.4
Return component with specified measures.
Requires the following permission: 'Browse' on the project of specified component.
Parameters
Parameter
Required?
Since
Description
Example value
additionalFields
optional
Comma-separated list of additional fields that can be returned in the response.
Possible values: metrics, period, periods Example value: period,metrics
branch
optional
6.6
Branch key. Not available in the community edition.
Example value: feature/my_branch
component
required
Component key
Example value: my_project
metricKeys
required
Comma-separated list of metric keys
Example value: ncloc,complexity,violations
pullRequest
optional
7.1
Pull request id. Not available in the community edition.
Example value: 5461
Response Example
{
"component": {
"key": "MY_PROJECT:ElementImpl.java",
"name": "ElementImpl.java",
"qualifier": "FIL",
"language": "java",
"path": "src/main/java/com/sonarsource/markdown/impl/ElementImpl.java",
"measures": [
{
"metric": "complexity",
"value": "12",
"period": {
"value": "2",
"bestValue": false
}
},
{
"metric": "new_violations",
"period": {
"value": "25",
"bestValue": false
}
},
{
"metric": "ncloc",
"value": "114",
"period": {
"value": "3",
"bestValue": false
}
}
]
},
"metrics": [
{
"key": "complexity",
"name": "Complexity",
"description": "Cyclomatic complexity",
"domain": "Complexity",
"type": "INT",
"higherValuesAreBetter": false,
"qualitative": false,
"hidden": false,
"custom": false
},
{
"key": "ncloc",
"name": "Lines of code",
"description": "Non Commenting Lines of Code",
"domain": "Size",
"type": "INT",
"higherValuesAreBetter": false,
"qualitative": false,
"hidden": false,
"custom": false
},
{
"key": "new_violations",
"name": "New issues",
"description": "New Issues",
"domain": "Issues",
"type": "INT",
"higherValuesAreBetter": false,
"qualitative": true,
"hidden": false,
"custom": false
}
],
"period": {
"mode": "previous_version",
"date": "2016-01-11T10:49:50+0100",
"parameter": "1.0-SNAPSHOT"
}
}
Changelog
Version
Change
8.8
deprecated response field 'id' has been removed.
8.8
deprecated response field 'refId' has been removed.
8.1
the response field periods under measures field is deprecated. Use period instead.
8.1
the response field periods is deprecated. Use period instead.
7.6
The use of module keys in parameter 'component' is deprecated
6.6
the response field 'id' is deprecated. Use 'key' instead.
6.6
the response field 'refId' is deprecated. Use 'refKey' instead.

Azure DevOps API - how to discover link between field and picklist

I'm trying to replicate an Azure DevOps process from one organization to another via the AZDO REST Api. I'm working on replicating the layout and am stuck because I can't discover the relationship between a custom field and a picklist when querying the source AZDO instance.
In my scenario I have a test work item type which I've called Issue. On the Issue interface I've created a custom field which is a picklist. While I can retrieve a list of lists via the Rest API and examine the field as well, I can't figure out how the two are related.
Here is a partial payload from the field:
{
"count": 39,
"value": [
...
{
"referenceName": "Custom.IssueSource",
"name": "Issue Source",
"type": "string",
"description": "Who is this attributed to",
"required": true,
"url": "https://dev.azure.com/MYORG/_apis/work/processes/f390103e-7097-4f19-b5b5-f9dbcf92bb6f/behaviors",
"customization": "custom"
},
... ]
}
and here is a partial payload from the lists get query which I used trial and error to determine was the picklist I've assigned:
{
"count": 10,
"value": [
...
{
"id": "2998d4e4-2bec-4935-98a1-b67a0b0b6d5d",
"name": "picklist_e854661e-8620-4ad9-be28-b974c5cb3a5d",
"type": "String",
"isSuggested": false,
"url": "https://dev.azure.com/MYORG/_apis/work/processes/lists/2998d4e4-2bec-4935-98a1-b67a0b0b6d5d"
},
...
]
}
Here is a partial layout response for the WIT:
{
"pages": [
{
"id": "d0171d51-ff84-4038-afc1-8800ab613160.System.WorkItemType.Details",
"inherited": true,
"label": "Details",
"pageType": "custom",
"visible": true,
"isContribution": false,
"sections": [
{
"id": "Section1",
"groups": [
...
{
"id": "bf03e049-5062-4d82-b91d-4396541fbed2",
"label": "Custom",
"isContribution": false,
"visible": true,
"controls": [
{
"id": "Custom.IssueSource",
"label": "Issue Source",
"controlType": "FieldControl",
"readOnly": false,
"visible": true,
"isContribution": false
}
]
}
]
},
... ]
}
Using fiddler against the AZDO web interface, the only time I see a reference to the picklist is from another non-AZDO API to https://dev.azure.com/MYORG/_apis/Contribution/dataProviders/query
Is there a way to discover the link via the AZDO Rest API? I saw this question which was similar but was about creating the link
Figured it out. Turns out you need to query from a different scope - work item tracking rather than work item tracking process:
https://dev.azure.com/MYORG/_apis/wit/fields/Custom.IssueSource?api-version=5.0-preview.2
returns
{
"name": "Issue Source",
"referenceName": "Custom.IssueSource",
"description": "Who is this attributed to",
"type": "string",
"usage": "workItem",
"readOnly": false,
"canSortBy": true,
"isQueryable": true,
...
"isIdentity": false,
--> "isPicklist": true,
"isPicklistSuggested": false,
--> "picklistId": "2998d4e4-2bec-4935-98a1-b67a0b0b6d5d",
"url": "https://dev.azure.com/MYORG/_apis/wit/fields/Custom.IssueSource"
}

Loopback - GET model using custom String ID from MongoDB

I'm developing an API with loopback, everything worked fine until I decided to change the ids of my documents in the database. Now I don't want them to be auto generated.
Now that I'm setting the Id myself. I get an "Unknown id" 404, whenever I hit this endpoint: GET properties/{id}
How can I use custom IDs with loopback and mongodb?
Whenever I hit this endpoint: http://localhost:5000/api/properties/20020705171616489678000000
I get this error:
{
"error": {
"name": "Error",
"status": 404,
"message": "Unknown \"Property\" id \"20020705171616489678000000\".",
"statusCode": 404,
"code": "MODEL_NOT_FOUND"
}
}
This is my model.json, just in case...
{
"name": "Property",
"plural": "properties",
"base": "PersistedModel",
"idInjection": false,
"options": {
"validateUpsert": true
},
"properties": {
"id": {"id": true, "type": "string", "generated": false},
"photos": {
"type": [
"string"
]
},
"propertyType": {
"type": "string",
"required": true
},
"internalId": {
"type": "string",
"required": true
},
"flexCode": {
"type": "string",
"required": true
}
},
"validations": [],
"relations": {},
"acls": [],
"methods": []
}
Your model setup (with with idInjection: true or false) did work when I tried it with a PostGreSQL DB setup with a text id field for smaller numbers.
Running a Loopback application with DEBUG=loopback:connector:* node . outputs the database queries being run in the terminal - I tried it with the id value you are trying and the parameter value was [2.002070517161649e+25], so the size of the number is the issue.
You could try raising it as a bug in Loopback, but JS is horrible at dealing with large numbers so you may be better off not using such large numbers as identifiers anyway.
It does work if the ID is an alphanumeric string over 16 characters so there might be a work around for you (use ObjectId?), depending on what you are trying to achieve.