How to update Test execution status ( Pass/Fail) in Jira in automatically using protractor framework.
Test management tool used Jira with zephyr plugin.
Any Rest API plugin available? Please provide example.
Any help would be appreciated.
In order to update the execution status you need to perform a REST call with this details:
Method: PUT
URL: https://{your_company_jira_url}/jira/rest/zapi/latest/execution/{executionId}/execute
Headers:
Content-Type: application/json
And in body specify this JSON:
For PASS:
{ "status": 1 }
For FAIL:
{ "status": 2 }
You can find more information (depending of your Zephyr/Jira version) in: https://zfjcloud.docs.apiary.io/#
I hope helps.
Related
I'm trying to send the status of a build pipeline to Bitbucket Server after the build is successful/failed.
With Postman, I'm able to successfully update the build status of a commit with the REST API:
POST https://bitbucketserver/rest/build-status/1.0/commits/dac37f9ede70e9548528a1dd19409b352db624e6
204
177 ms
Warning: Self signed certificate in certificate chain
POST /rest/build-status/1.0/commits/dac37f9ede70e9548528a1dd19409b352db624e6 HTTP/1.1
Authorization: Basic eHhrbGk6MjlOb3ZlbWJlcjIwMjA=
Content-Type: application/json
User-Agent: PostmanRuntime/7.26.8
Accept: */*
Postman-Token: e88d324b-e014-48e6-9a4c-5ad094e49aed
Host: nibcoderepo:7990
Accept-Encoding: gzip, deflate, br
Connection: keep-alive
Content-Length: 220
{
"state": "SUCCESSFUL",
"key": "Project",
"name": "CI-Build",
"url": "https://devops/Project/Repo/_build",
"description": "Build status from Azure Devops Server"
}
HTTP/1.1 204 No Content
However when I try to run the Invoke REST API in an agentless job in the pipeline, the request fails and is not able to find the server. Here's the output from the job log:
==============================================================================
Task : Post build status
Description : Invoke a REST API as a part of your pipeline.
Version : 1.152.1
Author : Microsoft Corporation
Help URL : https://learn.microsoft.com/azure/devops/pipelines/tasks/utility/http-rest-api
==============================================================================
Parsing expression: <TaskInputs[TaskInputs['connectedServiceNameSelector']]>
TaskInputs
[
..TaskInputs
..[
....'connectedServiceNameSelector'
..]
]
Evaluating: TaskInputs[TaskInputs['connectedServiceNameSelector']]
Evaluating indexer:
..Evaluating TaskInputs:
..=> Object
..Evaluating indexer:
....Evaluating TaskInputs:
....=> Object
....Evaluating String:
....=> 'connectedServiceNameSelector'
..=> 'connectedServiceName'
=> '3f2eef60-1c18-4d2d-95ef-20b9946e6a16'
Result: '3f2eef60-1c18-4d2d-95ef-20b9946e6a16'
POST https://bitbucketserver//rest/build-status/1.0/commits/b63a3c20f0b0df1fcaa163284f82e6efa9e84437
Request body: {
"state": "SUCCESSFUL",
"key": "Project",
"name": "CI-Build",
"url": "https://devops/Project/Repo/_build/results?buildId=822",
"description": "Build status from Azure Devops Server"
}
Response Code: 0
Response: An error was encountered while processing request. Exception: <!DOCTYPE html><html lang="en"><head><meta charset="utf-8"><meta http-equiv="X-UA-Compatible" content="IE=edge"><title>Oops, can't find that - Bitbucket</title><script>
....
Exception Message: The remote server returned an error: (404) Not Found. (type WebException)
I'm able to run the Postman request from the Azure DevOps machine, so there is no firewall issue.
Interestingly, I noticed that the address the REST call goes out to has a weird // after the machine address, don't know if that's something that could cause the issue...?
Since there is no post-execution gate in Azure DevOps build pipelines (similar to the release gates), I haven't figured out a better way to do this.
Has anyone else been successful in this?
Thanks,
Karri
According to this document, you can try do with a simple script in your pipeline and update with the build id.
script: |
import os
id = os.getenv('BUILD_BUILDID')
print(id)
Here is a case with similar issue you can refer to.
I was able to solve the connection issue in the end.
The reason for this is rather stupid, and was in fact related to the formation of the POST request URL in the task. Removing the first /-character worked and now the request is successfully sent to Bitbucket Server.
We use a web activity in ADF v2 to interact with the Azure Automation Account API (Job creation) based on this specification https://learn.microsoft.com/en-us/rest/api/automation/job/create
Since 09-04-2020 the PUT web call isn't working because the header "Content-Type : application/json" is not being sent. The pipeline that contain the activity hasn't changed in months, just stopped working suddenly with the error:
Operation on target Automation - AAS Processing failed:
{
"code": "UnsupportedMediaType",
"message": "{\"Message\":\"The request entity's media type 'text/plain' is not supported for this resource.\"}"
}
But the input request for the pipeline, does include the header:
{
"url": "https://management.azure.com/subscriptions/xxxxx/resourceGroups/xxxxx/providers/Microsoft.Automation/automationAccounts/xxxxx/jobs/55a1bfa2-340c-4120-ba42-43df9e9f4e14?api-version=2017-05-15-preview",
"method": "PUT",
"headers": {
"Content-type": "application/json"
},
"body": "{\"properties\":{\"runbook\":{\"name\":\"aas-masterdata-management\"},\"parameters\":{\"Masterdata_Table\":\"RLS\"},\"runOn\":\"\"}}",
"authentication": {
"type": "MSI",
"resource": "https://management.azure.com"
}
}
I've tried so far:
Recreate the pipeline
Test in a different ADF instance
Delete and redeploy all the pipelines
Delete the header
Change the header to lowercase, uppercase, etc
Add the header twice
Use a self-hosted integration runtime
Test in Debug mode
Any of these tests have been successful. Just for confirmation, I've run the same call from Postman and from the rest api debug tool included within the Api documentation, both worked perfectly, if I set the content header to text/plain in postman or in the web tool I get exactly the same error than in ADF v2. It seems that something has changed in the web call activity of ADF v2 that hardcodes the content header as "text/plain" somehow.
Is someone facing this same issue ? As I said, pipeline definition hasn't changed in months, just stopped working few days ago.
Answer from the ADF platform team:
I got update from Product team that using "Content-Type" instead of "Content-type" will resolve this issue. This can be referred in the documentation
It seems that they accepted "Content-type" before, as it was working several months with that config, but not anymore. So if someone experiences the same problem, here is the answer.
Thanks.
If you are creating the ADF webhook activity using a bicep file, I found this approach works to set the Content-Type in the header parameter.
Define a string variable with the hyphenated Content-Type name
Use string interpolation to include the variable in the headers param
var contentType = 'Content-Type'
activities: [
{
dependsOn: []
description: ''
name: 'MyWebHook'
userProperties: []
type: 'WebHook'
typeProperties: {
body: {
value: '#json(concat(\'{"data":"\',item().data,\'","startTime":"\',item().startTime,\'","endTime\\":"\',item().endTime,\'"}\'))'
type: 'Expression'
}
headers: {
'${contentType}': 'application/json'
}
method: 'POST'
reportStatusOnCallBack: true
timeout: '00:10:00'
url: listCallbackURL('${logic_app_id}/triggers/manual', '2016-10-01').value
}
}
]
Is it possible to read the Nexus 2.14 log (the one you see in Administration -> Logging) per http access (REST)?
If not, are there other means to read it from an external program?
There's an option to download the logs from the Log tab in Nexus.
Once you have downloaded the file, your browser will capture the URL from where it was downloaded, which will be listed in the downloads section of your browser.
You can use the below methods to fetch the logs,
Fetching the logs using curl:
curl -u uname:pass http://nexusURL/nexus/service/siesta/logging/log
Fetching the logs in Node.js using the request module:
var request = require('request')
var opts = {
headers: { Authorization: "Basic YWRtaW46YWRtaW4=" }, //For admin:admin
uri: 'http://nexusURL/nexus/service/siesta/logging/log',
method: "GET"
}
request(opts,function(err, res, body){
console.log(body)
}
);
It seems that
http://localhost:8081/nexus/service/siesta/logging/log
gives you the recent log file (found by trial and error).
I want to change the project owner of a project using REST API. I know there is a "/Owner" endpoint and I can get the owner without any problems with the following GET:
site/_api/ProjectServer/Projects('2cc734f2-cd16-4f09-8632-a2bc74a32577')/Owner
So how do I change the project owner using REST API?
This is an old issue but I figured it might help someone since I recently struggeled with this too.
I have only tested this on Project Online and not on-prem, probably works the same on Project Server 2016
Start by checking out the project
Send a PATCH request to:
_api/ProjectServer/Projects('PROJECT ID')/Draft
with the following headers:
Accept: application/json; odata=verbose
Content-Type: application/json; odata=verbose
X-RequestDigest: The request digest
If-Match: Either "*" or the etag value you get from checking out the project
and the request body:
{
"__metadata": {
"type": "PS.DraftProject"
},
"OwnerId": "SharePoint User ID of the owner"
}
It's important that you send the "OwnerId" value as a string, not a number.
Publish the project
The general way to change site owners using REST API according to MSDN is:
POST http://<sitecollection>/<site>/_api/site/owner
So in your case you should just have to change from a GET command to POST
http://wiki.processmaker.com/3.0/REST_API_Designer#get_projects
this api return all projects in my workflow including that I have not involved in. Any way to get projects that I can start?
I was told "/api/1.0/workflow/light/start-case" would get the projects I involved, while "/projects" get all projects.
Well, you have to execute these steps, for example in Postman:
For Desktop
GET: {{url}}/{{workspace}}/oauth2/token
url: Your Site
workspace: Your Workspace
**Headers**
Authorization: Basic eC1wbS1sb2NhbC1jbGllbnQ6MTc5YWQ0NWM2Y2UyY2I5N2NmMTAyOWUyMTIwNDZlODE=
Content-Type: application/json
{
"grant_type":"password",
"username":"admin",
"password":"admin"}
Now that we already have the access_token we need to try it out in the next endpoints
GET: {{url}}/api/1.0/{{workspace}}/light/start-case
url: Your Site
workspace: Your Workspace
**Headers:**
Authorization: Bearer {{access_token}}