Micro Focus Quality Center, formerly known as HP Quality Center is a quality management software. You can go through https://www.microfocus.com/en-us/products/alm-quality-center/overview to find out the benefits provided by ALM QC
I had a requirement to create a QC defect through Jenkins, It was on the old HP ALM environment when QC was not taken over by MicroFocus where I faced a few issues which I was able to resolve.
I created a Jenkins Job and configured it as shown in the below screenshots.
I provided the XML input to my curl command which will create QC defect based on provided Jenkins parameters.
After configuring the Job. Saved the Job and Triggered the job by the ‘Build with Parameters’ option.
Provide all the parameters.
The build was completed and Verified the Console output.
Now, the above can be considered as the happy path which will help you to create the QC defect programmatically either by Jenkins or any other tools, but I found a few issues when I was writing the code for the same and would like to share as it was quite interesting 🙂
Initially, I followed the official guides and tried to authenticate:
curl -c qc_cookies -u admin:******** http://qcserver:8084/qcbin/authentication-point/authenticate
By which I was able to authenticate (tried in both browser and curl). To verify my authentication, I used:
curl --cookie cookies.txt --cookie-jar cookies.txt http://localhost:8084/qcbin/rest/is-authenticated
It was showing the user name as part of authentication. So I was pretty sure my connection is established and I got the right cookies.
Then I tried to list out the defects – to do that I used:
curl --cookie cookies.txt --cookie-jar cookies.txt http://qcserver:8084/qcbin/rest/domains/DOM/projects/PROJ/defects
But when you hit the API, the login was not remaining authenticated and it’s asking for a new login, which was not working and giving different errors, such as:
401 – with login not given
302 – since it was redirecting to the login page
Then I checked the 12.53 REST APIs documentation: I got to know about one more term – Instead of using rest in URL – I tried with API.
After reviewing it, I fired:
curl -c qc_cookies -u admin:****** http://qcserver:8084/qcbin/api/authentication-point/authenticate
It prompted me to try with sign-in URL, then I changed my command to this:
curl -c qc_cookies -u admin:******** http://qcserver:8084/qcbin/api/authentication/sign-in -v
I had then verified with this:
curl -b qc_cookies http://localhost:8084/qcbin/rest/is-authenticated
I had then listed out the defects:
curl -b qc_cookies -c qc_cookies -H "Content-Type: application/json" -X GET http://qcserver:8084/qcbin/api/domains/DOM/projects/PROJ/defects
It has successfully shown the defects.
But when I fired this create defect command it was throwing an error:
HTTP/1.1 415 Unsupported Media Type: "Id":"qccore.general-error","Title":"Unsupported Media Type"
curl -b qc_cookies -c qc_cookies -X POST -d @post-defect.json http://qcserver:8084/qcbin/rest/domains/DOM/projects/PROJ/defects/ -v
I found a nice explanation which states:
It looks like the issue has to do with the difference between the Content-Type and Accept headers. In HTTP, Content-Type is used in request and response payloads to convey the media type of the current payload. Accept is used in request payloads to say what media types the server may use in the response payload.
So, having a Content-Type in a request without a body (like your GET request) has no meaning. When you do a POST request, you are sending a message body, so the Content-Type does matter.
If a server is not able to process the Content-Type of the request, it will return a 415 HTTP error. (If a server is not able to satisfy any of the media types in the request Accept header, it will return a 406 error.)
In OData v3, the media type “application/json” is interpreted to mean the new JSON format (“JSON light”).
If the server does not support reading JSON light, it will throw a 415 error when it sees that the incoming request is JSON light.
In your payload, your request body is verbose JSON, not JSON light, so the server should be able to process your request. It just doesn’t because it sees the JSON light content type.
I made a few changes and tried with JSON and XML but it was not helping and even got 500 Errors – then I made it in original form and changed the headers to show the odata verbose:
curl -b qc_cookies -c qc_cookies -H "Accept: application/xml;odata=verbose" -H "Content-Type: application/xml" -X POST -d @post-defect.xml http://qcserver:8084/qcbin/rest/domains/DOM/projects/PROJ/defects
It showed me what was wrong with my provided JSON or XML and once I fixed it – I was able to create the defect and used correct syntax in my Jenkins job.
Hope it helps you in creating HP QC defects from Jenkins…