Creating a Gadget that executes a Groovy script

[Eric_Dejouhanet]

Hello,

I have been using Script Runner for some time now, and as many others have found before, pairing Groovy and JIRA is an excellent idea. Newbie-friendly, nicely concise, and maintainability is quite good.

However, using Script Runner as support engine seem to limit the use of Groovy scripts to either Issues or administration work.

How can I, for instance, create a gadget that executes a Groovy script located on the server? As an example, a gadget to display a green/red status for a version, obtained from an external build server.

First I thought that Script Runner would provide a REST API, but I noted in the 3.x release notes that:

"Script Runner 2.x had an undocumented REST API which allowed you to run scripts. The path to this has been replaced. You can work out the new URLs by using the network tab in your browser development tools console."

I created a Scripted Field, assigned it the simple "issue.key" custom script, and found that it was calling plugins/servlet/com.onresolve.ScriptedFieldPreviewServlet, with form data probably. Same when providing a script path.

I displayed that Scripted Field in an Issue, and found that it was calling /plugins/servlet/com.onresolve.ScriptedFunctionDocsServlet?_=1424771904603, but I'm not sure that is relevant.

So I'm afraid I can't work out anything except Scripted Fields (which is already quite nice, of course).

[JamieA]

So, 3.0 has a rest api but it requires admin rights to use it, so it's not suitable for a gadget.

A future version will support pluggable REST APIs, whereby you just define the names of your endpoints in a simplified way, like so:

someGet(httpMethod: "GET", groups: ["jira-users"]) { MultivaluedMap queryParams ->
    return Response.ok(new JsonBuilder("you got it").toString()).build();
}

The method parameters instruct on who can access it, what verbs to support etc. It does not support the full panoply of JAX-RS annotations though.

You would annotate such scripts with eg @CustomRestEndpoint and script runner will find them under the script roots, recompiling them on demand if they change, which makes dev easy and fun.

A gadget is not much more than some resources (javascript, css etc) and a rest call or three. The resources can be defined in the normal way (ie with <web-resource> blocks, in a scripts plugin.

Most of the work is complete, it's just awaiting some documentation and examples, and a few of the finer points ironing out (which generally take 80% of the time). 

Until it's released though I think you will find it painful pursuing this approach. I hope it will be released within a month or two.

[Eric_Dejouhanet]

Currently the less painful way I found is to tinker with a proof-of-concept using the Script Runner Console, then translate the script to pure Java, then integrate it as a REST endpoint in a plug-in. Still painful, considering the effort required to set a development chain on JIRA plug-ins when you're not in the Java business. But well, it's also the preferred packaging for gadgets, so...

[JamieA]

that's the way I'd do it too...

[MattS]

I'm looking forward to that

[Brian Bishop]

Can I expose a (version 3.0.16) groovy script to an external system via a REST endpoint that consumes POST body data? My external system can emit HTTPS requests when certain events happen in that system. Would be nice if it could affect changes in JIRA (like creating values for a custom field, or creating custom fields) via this or similar mechanism.

[JamieA]

you will be able to do this in the next version

[Eric_Dejouhanet]

Hum, reviewing my test server configuration: Jira 6.1.2, Script Runner 2.1.16. So I guess mentioning the undocumented REST API is now a bit weird. But the question still stands for production :)