How to update a test execution when importing Junit Multipart using Xray? - jenkins

I was looking at the documentation of the Xray plugin for Jenkins: https://docs.getxray.app/display/XRAY/Import+Execution+Results+-+REST#ImportExecutionResultsREST-JUnitXMLresultsMultipart
And what I found, is a bit confusing, after a few attempts.
If I'm NOT trying to import executions using the multipart, I can update a test execution by specifying a Test Execution Key.
When I do try the multipart, I have this JSON
"fields": {
"project": {
"key": "${ProjectKey}"
},
"summary": "Temp Test execution",
"issuetype": {
"name": "Test Execution"
},
"labels": [],
"fixVersions": [
{
"name": "testrelease"
}
]
}
}
This always creates a new Test Execution within JIRA.
In their examples I see no way to send the test execution key for it to be updated.
Which is strange, because by importing without multipart, I can set it.
Anyone has any idea how to achieve this?

Currently, if you use the "multipart" kind of endpoints, a new Test Execution will always be created. To update existing Test Execution issues you need to use the standard endpoints (e.g., JUnit); however, these don't allow you to customize fields on the Test Execution.
There's an improvement in the backlog in order to enhance the existing behaviour; please vote on it and watch it, so the Xray team can become aware of your interest on this.

Related

Twilio Studio API and updating the function_sid between accounts

When using the new Studio API to import and export Studio flow JSON everything transfers correctly, however when importing from another account there are issues translating functions.
The service and environment sid can be replaced for the entire flow. While not ideal the process could however be automated. The real problem is with the function sid .Finding the function_sid would need to be manual or an api call to retrieve making this a more complicated process.
Currently the other option is to open the flow in the UI and mannual select the correct function. Is there a better way to do this?
Here is an example of the area of JSON that is an issue.
"properties": {
"service_sid": "<Your-service-sid-unique-to-account>",
"environment_sid": "<Your-environment-sid-unique-to-account/service>",
"offset": {
"x": -1230,
"y": -7330
},
"function_sid": "<Your-function-sid-unique-to-function>",
"parameters": [
{
"value": "{{trigger.message.From}}",
"key": "from"
}
],
"url": "https://<function-endpoint>.twil.io/data/<function>"
}
From one of my collegues:
I would set the FQDN of the Twilio Function using liquid syntax in the Run Function Widget, that way the customer only has to update their Set Variables Widget in the case of having multiple function calls

Create a Task on TFS With Backdated/History Date

The problem is i want to create a task on my TFS with backdated dates
I didn't find anything on internet Kindly suggest me a way either from GUI or APIs
You can use the rest api with the bypassRules parameter to set the created date to whatever date you need.
bypassRules : Do not enforce the work item type rules on this update
POST https://{instance}/{collection}/{project}/_apis/wit/workitems/$Task?bypassRules=true&api-version=5.0
Sample request body:
[
{
"op": "add",
"path": "/fields/System.CreatedDate",
"value": "2020-06-05T02:28:18.603Z"
}
]
Test in Postman:

Retrieving labels from multiple JIRA Subtasks via JIRA API

I am creating a reporting dashboard with the intent of getting multiple tickets/issues for a project. As most of you probably know, a JIRA issue can have subtasks. These subtasks can have labels.
I want to retrive all labels for every subtask.
I already have the project API request implemented which returns the parent ticket ids along with the issue/ticket number of all subtasks. The problem is the data returned from this request does not include the labels for the subtasks themselves.
I can loop over each subtask number and make an additional API request for each one to get the labels, however this would result in a large number of requests.
Looking through JIRA's API I cannot find a better way of doing this. Google seems to return a lot of results about plugins and version differences with Cloud vs. Server but I have not found a better solution.
Their API makes reference to an expand option but I have yet to figure out a way to make that work for subtask labels (I might be missing something obvious).
If anyone has experience with a similar situation I would appreciate hearing any advice you could offer. Thanks!
What I have currently:
Project API Request:
https://ourcompanyhere.atlassian.net/rest/api/2/search
with an additional parameter added for the JQL string of:
project=PROJECTNAME AND fixversion=version
This returns all the tickets in the project with subtasks but not the subtask labels.
I can loop over the returned data from the above request and make an additional request for each:
https://ourcompanyhere.atlassian.net/rest/api/2/issue/ticketNumberHere
JSON Response
Here is the partial JSON response back (full response is huge and I've removed key information) however this is the complete information for a ticket, with a subtask which has labels. As you can see the labels section of the subtask is completely missing.
ErrorDetail=,
Mimetype=application/json,
Statuscode=200 OK,
Filecontent= {
"expand":"schema,names",
"startAt":0,
"maxResults":50,
"total":3,
"issues":[
{
"expand":"operations,versionedRepresentations,editmeta,changelog,renderedFields",
"id":"24209",
"self":"https://[instance].atlassian.net/rest/api/latest/issue/24209",
"key":"DEV-3089",
"fields":{
"issuetype":{
"self":"https://[instance].atlassian.net/rest/api/2/issuetype/10005",
"id":"10005",
"description":"A new feature of the product, which has yet to be developed.",
"iconUrl":"https://[instance].atlassian.net/secure/viewavatar?size=xsmall&avatarId=10311&avatarType=issuetype",
"name":"New Feature",
"subtask":false,
"avatarId":10311
},
"project":{
"self":"https://[instance].atlassian.net/rest/api/2/project/10000",
"id":"10000",
"key":"DEV",
"name":"Development Queue",
"avatarUrls":{
}
},
"customfield_11000":null,
"fixVersions":[
{
"self":"https://[instance].atlassian.net/rest/api/2/version/14600",
"id":"14600",
"description":"",
"name":"",
"archived":false,
"released":true,
"releaseDate":"2017-09-15"
}
],
"resolution":{
"self":"https://[instance].atlassian.net/rest/api/2/resolution/10000",
"id":"10000",
"description":"Work has been completed on this issue.",
"name":"Done"
},
"customfield_10500":"",
"customfield_10700":null,
"customfield_10900":null,
"resolutiondate":"2017-09-15T09:19:37.000-0400",
"workratio":-1,
"watches":{
"self":"https://[instance].atlassian.net/rest/api/2/issue/DEV-3089/watchers",
"watchCount":2,
"isWatching":true
},
"lastViewed":null,
"created":"2017-05-02T10:15:08.000-0400",
"customfield_10022":null,
"customfield_10100":null,
"priority":{
"self":"https://[instance].atlassian.net/rest/api/2/priority/3",
"iconUrl":"https://[instance].atlassian.net/images/icons/priorities/medium.svg",
"name":"Medium",
"id":"3"
},
"customfield_10300":null,
"labels":[
"[label1]",
"[label2]",
"[label3]",
"[label4]",
"[label5]",
"[label6]"
],
"customfield_10016":null,
"customfield_10017":null,
"versions":[
],
"issuelinks":[
],
"assignee":{
"self":"https://[instance].atlassian.net/rest/api/2/user?username=",
"name":"[name]",
"key":"[name]",
"accountId":"[account]",
"emailAddress":"[email]",
"avatarUrls":{
},
"displayName":"[name]",
"active":true,
"timeZone":"America/New_York"
},
"updated":"2017-09-15T09:19:36.000-0400",
"status":{
"self":"https://[instance].atlassian.net/rest/api/2/status/6",
"description":"The issue is considered finished, the resolution is correct. Issues which are closed can be reopened.",
"iconUrl":"https://[instance].atlassian.net/images/icons/statuses/closed.png",
"name":"Closed",
"id":"6",
"statusCategory":{
"self":"https://[instance].atlassian.net/rest/api/2/statuscategory/3",
"id":3,
"key":"done",
"colorName":"green",
"name":"Done"
}
},
"components":[
],
"description":"[description]",
"customfield_10010":null,
"customfield_10011":null,
"customfield_11100":null,
"customfield_10012":null,
"customfield_10013":null,
"customfield_10015":"",
"customfield_10005":null,
"customfield_10006":null,
"customfield_10600":null,
"customfield_10007":null,
"customfield_10008":null,
"customfield_10800":null,
"customfield_10009":null,
"summary":"[summary]",
"creator":{
"self":"https://[instance].atlassian.net/rest/api/2/user?username=",
"name":"",
"key":"",
"accountId":"",
"emailAddress":"",
"avatarUrls":{
},
"displayName":"",
"active":true,
"timeZone":"America/New_York"
},
"subtasks":[
{
"id":"30213",
"key":"DEV-4118",
"self":"https://[instance].atlassian.net/rest/api/2/issue/30213",
"fields":{
"summary":"",
"status":{
"self":"https://[instance].atlassian.net/rest/api/2/status/6",
"description":"The issue is considered finished, the resolution is correct. Issues which are closed can be reopened.",
"iconUrl":"https://[instance].atlassian.net/images/icons/statuses/closed.png",
"name":"Closed",
"id":"6",
"statusCategory":{
"self":"https://[instance].atlassian.net/rest/api/2/statuscategory/3",
"id":3,
"key":"done",
"colorName":"green",
"name":"Done"
}
},
"priority":{
"self":"https://[instance].atlassian.net/rest/api/2/priority/3",
"iconUrl":"https://[instance].atlassian.net/images/icons/priorities/medium.svg",
"name":"Medium",
"id":"3"
},
"issuetype":{
"self":"https://[instance].atlassian.net/rest/api/2/issuetype/10009",
"id":"10009",
"description":"",
"iconUrl":"https://[instance].atlassian.net/secure/viewavatar?size=xsmall&avatarId=10303&avatarType=issuetype",
"name":"Testing Issue",
"subtask":true,
"avatarId":10303
}
}
}
"reporter":{
"self":"https://[instance].atlassian.net/rest/api/2/user?username=",
"name":"",
"key":"",
"accountId":"",
"emailAddress":"",
"avatarUrls":{
},
"displayName":"",
"active":true,
"timeZone":"America/New_York"
},
"customfield_10000":"2017-09-01T12:35:54.706-0400",
"customfield_10001":null,
"customfield_10200":null,
"customfield_10400":null,
"customfield_10004":null,
"environment":null,
"duedate":null,
"votes":{
"self":"https://[instance].atlassian.net/rest/api/2/issue/DEV-3089/votes",
"votes":0,
"hasVoted":false
}
}
}
]
}
Inspect the response for the /search endpoint again. On a completely empty JIRA Cloud instance I created a Project, one Issue and added a Sub-task for it. Calling the /search endpoint returns a list with two Issues (so, the Issue itself and its Sub-task) and for both there's a field called labels with an array of all the Labels attached to it.
The following is an abbreviated response with all unrelated data removed.
{
"startAt": 0,
"maxResults": 50,
"total": 2,
"issues": [
{
"key": "TEST-1",
"fields": {
"labels": []
}
},
{
"key": "TEST-2",
"fields": {
"parent": {
"key": "TEST-1"
},
"labels": [
"VOILA"
]
}
}
]
}
EDIT
After looking at the response then yes, the array in subtasks is really simple and cannot be separately expanded. You need to do the search, then parse out all the subtasks that you're interested in and either do
a separate /issue/[key] request for each one
a /search for those specific keys
After doing some further research I found a better way to do this. I'm still not getting the subtask labels back but instead of looping over each subtask and sending a separate request for each, you can do one API call using JQL like this:
https://[instance].atlassian.net/rest/api/latest/search?jql=project=[project] AND KEY IN ([comma separated list of tickets])&fields=labels'
The
&fields=labels
part drastically reduces the amount of information returned. So now I can just do a total of two calls and get everything I need. :)
Wanted to post this in case anyone runs into a similar situation.

TFS 2015U3 build REST api specify reuqired demands

I'm trying to use the TFS rest API to trigger various builds. Each build that gets triggered, requires different demands.
E.g. I tried something like:
{
"definition": {
"id": 190
},
"sourceBranch": "refs/heads/master",
"demands":{"XXXXXXX":""},
This build executes fine, although no Agent satisfies the demand. Also various variations didn't work as expected.
In the documentation https://www.visualstudio.com/en-us/docs/integrate/api/build/overview I was not able to find anything regarding demands.
How does the body need to look like, so that the demands work?
After inspecting my http traffic with fiddler I finally found out what the body needs to be to send demands:
$body = #"
{
"definition": {
"id": 190
},
"sourceBranch": "refs/heads/master",
"parameters": "{\"configuration\":\"Debug\"}",
"demands":["xxxxxxxxxxxxxxxxx","yyyyyyyyyyy -equals zzzzzzzzzzzzz"],
}
"#

Time from creation to closed

I am trying to calculate the average time for all the jira cases that are created and until they are resolved.
How can this be done, for a specific project?
You dont say how you want to calculate this.
The simplest way is to add the Resolution Time Gadget to your dashboard. Here you can add a filter to specify which issues you want to consider.
This will give you a nice bar chart of the average resolution times of issues over a given period
If you want more control, you can write a script for it with the Jira REST API
If you create a jql for the issues you are interested in, you can call the REST api with a url like this:
https://jira.intern.sparebank1.no/rest/api/2/search?jql=assignee=e6462u
This will return a whole bunch of info, but you are most interested in the issues array elements, and specifically the fields "created" and "resolutiondate"
A snipped version of the JSON returned is:
{
"expand": "schema,names",
"startAt": 0,
"maxResults": 50,
"total": 1,
"issues": [
{
"expand": "operations,versionedRepresentations,editmeta,changelog,transitions,renderedFields",
"id": "104799",
"self": "https://jira.domain.com/rest/api/2/issue/104799",
"key": "HELLO-1",
"fields": {
...
"resolutiondate": "2015-06-25T09:12:27.000+0200",
"created": "2015-03-18T16:18:38.000+0100"
...
}
}
]
}
Now you can calculate the difference between the two for each issue element and find an average.
More info on Jira REST API: https://docs.atlassian.com/jira/REST/latest/
A blog I wrote on how to script stuff like this (and present in a graph in confluence ;) ): http://javamemento.blogspot.no/2016/05/jira-confluence-3.html

Resources