February 25, 2014

Jenkins HP's ALM Quality Center (QC) REST integration

QC is definitely not something I'd spend money or time on, actually I'd try and stay away from it altogether. But at times bad decisions are made and these sub-optimal choices filled with blockers and tech-debt linger on.

Enough ranting, the topic of this post is that it turns out there are still companies out there that don't have Continuous Integration at all. And introducing CI alone isn't enough to make people care about the build health it's health and whether it's alerting the team of bad things that no one was aware of. Still, at least in this particular place, QC reigns supreme. If bugs are logged in QC people will fight them. There are triage meetings and QC-report-fueled bug squashing rounds.

So integration seemed like a good way to get people's attention. Simple plan. Every time a build in Jenkins fails it automagically creates a defect in QC, voila!

I started off down the wrong path by installing Quality Center in a Windows VM and started hunting for the elusive OTAClient.dll, that was a bad idea. First because I don't want my Jenkins instance running on Windows and second I can't install QC everywhere due to licencing constraints.

Turns out that version 11 has an API and going straight to it via HTTP proved a to be a simple exercise. Now things are slightly more elaborate than what I describe here but if you want the simplest solution possible with minimum coding, all you need to do is hook up a Conditional Step in Jenkins and, if it FAILs, call the curl commands below in three separate shell execs.

curl -b qc_cookies -c qc_cookies -u <USERNAME:PASSWORD> http://<QC_SERVER:PORT>/qcbin/authentication-point/authenticate

curl -b qc_cookies -c qc_cookies -H "Content-Type: application/xml" -X POST -d @<QC_DEFECT_PAYLOAD.xmlhttp://<QC_SERVER:PORT>/qcbin/rest/domains/<DOMAIN>/projects/<PROJECT>/defects

curl -b qc_cookies -c qc_cookies http://<QC_SERVER:PORT>/qcbin/authentication-point/logout

These commands will, in order, login, create the new defect via POST according to the XML file in QC_DEFECT_PAYLOAD.xml and logout.

Things to keep in mind:
  • Use a REST chrome extension like to iron out details before putting everything in Jenkins
  • Don't forget to create QC_DEFECT_PAYLOAD.xml and put that in your Jenkins workspace or a known location
  • Figuring out the mandatory fields is easy. Just do a GET on http://<QC_SERVER:PORT>/qcbin/rest/domains/<DOMAIN>/projects/<PROJECT>/customization/entities/defect/fields?required=true. I'm not sure if it's a validation bug with the installation I was using but some fields that were coming back as mandatory from the endpoint didn't seem to cause trouble if they weren't present in the POST
  • QC's api doco is quite helpful (sign-in required)
A lot can be done with a little bit of CURL magic.

No comments:

Post a Comment