I'm trying to make a Git push request to our Azure Devops server via the API. The address is https://MYSITE.visualstudio.com/MYPROJECT/_apis/git/repositories/2b34d4f7-2c1f-42e7-8861-u0ba34f72b40/pushes?api-version=5.1 and the body is as follows:
{
"commits": [
{
"comment": "Just a dummy commit",
"changes": [
{
"changeType": "edit",
"item": {
"path": "/src/MYPROJECT/MYPROJECT.csproj"
},
"newContent": {
"content": "beans",
"contentType": "rawText"
}
}
]
}
],
"refUpdates": [
{
"name": "refs/heads/TestDummyPRs/upgradeProjectToLatest",
"oldObjectId": "058da4f3328cb1048cb43faf3b5158bc3b025615"
}
]
}
I'm getting the following error:
Web Request Failed after 4 attempts. Request: https://MYSITE.visualstudio.com/MYPROJECT/_apis/git/repositories/2b34d4f7-2c1f-42e7-8861-u0ba34f72b40/pushes?api-version=5.1. Status: BadRequest. Response: Invalid status code [BadRequest]. Response: {"$id":"1","innerException":null,"message":"The parameters are incorrect. A posted push must contain exactly one commit and one refUpdate.\r\nParameter name: newPush","typeName":"Microsoft.TeamFoundation.SourceControl.WebServer.InvalidArgumentValueException, Microsoft.TeamFoundation.SourceControl.WebServer","typeKey":"InvalidArgumentValueException","errorCode":0,"eventId":0}
"A posted push must contain exactly one commit and one refUpdate" doesn't seem entirely reasonable as that's exactly what I have in my body. Does anybody know what might be going on here?
Note that I am having no issues making other web requests, such as creating branches or retrieving file contents.
I expected my web request to proceed smoothly, and to create a Push containing the specified commit to the specified refUpdate.
I have made a manual push for via the Azure Devops web interface and caught the network traffic, and I grabbed the following JSON request out of it:
{
"commits": [
{
"changes": [
{
"changeType": 2,
"item": {
"path": "/src/MYPROJECT/MYPROJECT.csproj"
},
"newContent": {
"content": "beans",
"contentType": 0
}
}
],
"comment": "Just a dummy commit"
}
],
"refUpdates": [
{
"name": ""refs/heads/TestDummyPRs/upgradeProjectToLatest",
"oldObjectId": "058da4f3328cb1048cb43faf3b5158bc3b025615"
}
]
}
This seems to be meaningfully identical to the Push I'm making from my code, other than the enum fields using numerical values instead of text. I have tried my code with numerical values for enums, but that didn't change anything about the error.
I found the issue. The web request from my application was being sent with UTF-16 encoding, whereas Postman had defaulted to UTF-8 encoding. I changed my application to use UTF-8 and it worked.
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.
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
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.
I'm trying to get list of JIRA issues created after a given date and download the respective attachment files from my application in java. The JIRA Server version I am currently using is 6.3.15.
When I searched on web I found the below REST client, however it says it supports till JIRA Server 6.0. I want to know whether it supports 6.3.15 as well, if not are there any other alternate solutions?
REST Java Client for JIRA
by Atlassian Labs for JIRA Server 5.0 - 6.0
https://marketplace.atlassian.com/plugins/com.atlassian.jira.jira-rest-java-client
REST Java Client for JIRA is a wrapper around JIRA REST https://docs.atlassian.com/jira/REST/6.3.15/.
I see that there was no changes in attachment REST methods between 6.0 and 6.3.15. Take the current version and I am sure it will work for you.
Another way is to directly use JIRA REST API and in your case it can be even simpler. I guess you need:
call https://YOUR_JIRA/rest/api/2/issue/CURRENT-ISSUE?fields=attachment for one issue or
https://YOUR_JIRA/rest/api/2/search?jql=YOUR_JQL&fields=attachment to return set of issues matching JQL query (make sure to take care about paging if you expect more than 1000 issues)
For each issue there will be a section with attachments:
"attachment":
[
{
"self": "https://vkrupach.atlassian.net/rest/api/2/attachment/10100",
"id": "10100",
"filename": "to test",
"author":
{
"self": "https://vkrupach.atlassian.net/rest/api/2/user?username=vkrupach",
"name": "vkrupach",
"key": "vkrupach",
"emailAddress": "vkrupach#ukr.net",
"avatarUrls":
{
"48x48": "https://vkrupach.atlassian.net/secure/useravatar?avatarId=10122",
"24x24": "https://vkrupach.atlassian.net/secure/useravatar?size=small&avatarId=10122",
"16x16": "https://vkrupach.atlassian.net/secure/useravatar?size=xsmall&avatarId=10122",
"32x32": "https://vkrupach.atlassian.net/secure/useravatar?size=medium&avatarId=10122"
},
"displayName": "Volodymyr Krupach [Administrator]",
"active": true,
"timeZone": "Europe/Moscow"
},
"created": "2015-04-19T10:05:59.696+0300",
"size": 469,
"mimeType": "text/html",
"content": "https://vkrupach.atlassian.net/secure/attachment/10100/to+test"
}
]
"content": is direct link to file.