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

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.

Related

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"
}

Update Stack w. "Replacement: Conditional"; will it replace?

Just updated some of our CF-templates and was going to update the stack it refers to. I've added some default values and added a CloudWatch alarm and I am also going to downgrade the instance from m4.xlarge to m4.large.
I've already downgraded the instance in the EC2-GUI and it went fine. I then reverted it to its default state as per the original template i.e. m4.xlarge.
However when I modify the default value in the template for the instancetype it does not reflect when I upload the modified template to CloudFormation.
Meaning the default value is still m4.xlarge and I have to use the drop-down menu to select m4.large as specified in my template.
If I don't change the instancetype I get:
"Replacement: False" but if I update the instancetype I get "Replacement: Conditional".
If I read more under "Changeset Details" and then "Details" I see:
[
{
"resourceChange": {
"logicalResourceId": "CPUAlarm",
"action": "Add",
"physicalResourceId": null,
"resourceType": "AWS::CloudWatch::Alarm",
"replacement": null,
"details": [],
"scope": []
},
"type": "Resource"
},
{
"resourceChange": {
"logicalResourceId": "myInstanceName",
"action": "Modify",
"physicalResourceId": "<masked>",
"resourceType": "AWS::EC2::Instance",
"replacement": "Conditional",
"details": [
{
"target": {
"name": null,
"requiresRecreation": "Never",
"attribute": "Tags"
},
"causingEntity": null,
"evaluation": "Dynamic",
"changeSource": "DirectModification"
},
{
"target": {
"name": null,
"requiresRecreation": "Never",
"attribute": "Tags"
},
"causingEntity": "Project",
"evaluation": "Static",
"changeSource": "ParameterReference"
},
{
"target": {
"name": null,
"requiresRecreation": "Never",
"attribute": "Tags"
},
"causingEntity": null,
"evaluation": "Static",
"changeSource": null
},
{
"target": {
"name": "InstanceType",
"requiresRecreation": "Conditionally",
"attribute": "Properties"
},
"causingEntity": "InstanceType",
"evaluation": "Static",
"changeSource": "ParameterReference"
},
{
"target": {
"name": "InstanceType",
"requiresRecreation": "Conditionally",
"attribute": "Properties"
},
"causingEntity": null,
"evaluation": "Dynamic",
"changeSource": "DirectModification"
}
],
"scope": [
"Properties",
"Tags"
]
},
"type": "Resource"
},
{
So what I can see is that:
"name": "InstanceType","requiresRecreation": "Conditionally", is the only value that has a more restrictive value and therefore the entire stack gets "Replacement: Conditional".
As per AWS:
"In some cases, AWS CloudFormation can determine a value only after you execute a change set. AWS CloudFormation labels those changes as Dynamic evaluations. For example, if you reference an updated resource that is conditionally replaced, AWS CloudFormation can't determine whether the reference to the updated resource will change."
Source:
https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-cfn-updating-stacks-changesets-samples.html#using-cfn-updating-stacks-changesets-samples-directly-editing-a-template
AFAIK "Replacement: Conditional" 'might' replace the resource i.e. creating a new physicalResourceID which in turn forces me to change associated SGs etc. but it might also not do it, correct?
Grateful for any assistance!
It's generally not recommended to modify resources created via CloudFormation, outside of CloudFormation. For your last question, Replacement: Conditional may or may not necessitate replacement of a resource based on what exactly you're trying to do. It's always helpful to look at the AWS CloudFormation docs whenever you have doubts though e.g. in your specific scenario of editing instance type of an EC2 instance, here's the what docs state:
Update requires: Some interruptions for Amazon EBS-backed instances
Update requires: Replacement for instance store-backed instances
Ref: http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-ec2-instance.html#cfn-ec2-instance-instancetype

How to get rid of the json attributes "variant", "annotations", from the response

I have started using the dropwizard to develop a REST server. The Issue as long resource-method return an EntityType (say Enrolment), the out put is as expected but I have decided to send custom status codes using the below code
Response.status(Response.Status.PRECONDITION_FAILED)
.entity(Entity.json(new enrolment, AdapterResponseStatus.FAILURE)))
.build();
Everything is fine but the out put now contains a few more extra extra attributes as shown below.
{
"entity":
{
"id": 1267,
"courseId": "5798890",
"userName": "user#abc.com",
"tenantId": "tenant1",
"status": "approved",
"link": "/enrollments/null"
},
"variant":
{
"language": null,
"mediaType":
{
"type": "application",
"subtype": "json",
"parameters":
{
},
"wildcardType": false,
"wildcardSubtype": false
},
"encoding": null,
"languageString": null
},
"annotations":
[
],
"mediaType":
{
"type": "application",
"subtype": "json",
"parameters":
{
},
"wildcardType": false,
"wildcardSubtype": false
},
"language": null,
"encoding": null
}
I was expecting "entity" property alone but was getting other attributes. Is there any to get rid of them as no one is going to consuming them?
Those tags appear even if I replace my entity object (enrolment) with an empty string.
If you look at the signature of the ResponseBuilder's entity method, it takes the object directly; unlike Jersey client which requires a special Entity object that coincidentally has annotations and variants fields within.
Change your code to this:
Response.status(Response.Status.PRECONDITION_FAILED)
.entity(new Enrolment())
.build();

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.

Swagger UI doesn't show embedded json properties model

I am using the swagger tool for documenting my Jersey based REST API (the swaggerui I am using was downloaded on June 2014 don't know if this issue has been fixed in later versions but as I made a lot of customization to its code so I don't have the option to download the latest without investing lot of time to customize it again).
So far and until now, all my transfer objects have one level deep properties (no embedded pojos). But now that I added some rest paths that are returning more complex objects (two levels of depth) I found that SwaggerUI is not expanding the JSON model schema when having embedded objects.
Here is the important part of the swagger doc:
...
{
"path": "/user/combo",
"operations": [{
"method": "POST",
"summary": "Inserts a combo (user, address)",
"notes": "Will insert a new user and a address definition in a single step",
"type": "UserAndAddressWithIdSwaggerDto",
"nickname": "insertCombo",
"consumes": ["application/json"],
"parameters": [{
"name": "body",
"description": "New user and address combo",
"required": true,
"type": "UserAndAddressWithIdSwaggerDto",
"paramType": "body",
"allowMultiple": false
}],
"responseMessages": [{
"code": 200,
"message": "OK",
"responseModel": "UserAndAddressWithIdSwaggerDto"
}]
}]
}
...
"models": {
"UserAndAddressWithIdSwaggerDto": {
"id": "UserAndAddressWithIdSwaggerDto",
"description": "",
"required": ["user",
"address"],
"properties": {
"user": {
"$ref": "UserDto",
"description": "User"
},
"address": {
"$ref": "AddressDto",
"description": "Address"
}
}
},
"UserDto": {
"id": "UserDto",
"properties": {
"userId": {
"type": "integer",
"format": "int64"
},
"name": {
"type": "string"
},...
},
"AddressDto": {
"id": "AddressDto",
"properties": {
"addressId": {
"type": "integer",
"format": "int64"
},
"street": {
"type": "string"
},...
}
}
...
The embedded objects are User and Address, their models are being created correctly as shown in the json response.
But when opening the SwaggerUI I can only see:
{
"user": "UserDto",
"address": "AddressDto"
}
But I should see something like:
{
"user": {
"userId": "integer",
"name": "string",...
},
"address": {
"addressId": "integer",
"street": "string",...
}
}
Something may be wrong in the code that expands the internal properties, the javascript console doesn't show any error so I assume this is a bug.
I found the solution, there is a a line of code that needs to be modified to make it work properly:
In the swagger.js file there is a getSampleValue function with a conditional checking for undefined:
SwaggerModelProperty.prototype.getSampleValue = function(modelsToIgnore) {
var result;
if ((this.refModel != null) && (modelsToIgnore[this.refModel.name] === 'undefined'))
...
I updated the equality check to (removing quotes):
modelsToIgnore[this.refModel.name] === undefined
After that, SwaggerUI is able to show the embedded models.