Version controlling ScriptRunner Jobs, Listeners, etc. in an air gapped environment

[Michael Wells]

Background

I work in an environment with many networks, most of which are air gapped with no access to the internet. My DevOps team wants to do as much development as possible on a single network while making it as easy as possible to create a baseline to push to other networks without making it difficult to view or modify for other networks as needed. Currently, we have ScriptRunner's scripts/ directory version controlled in a BitBucket repo which is directly pushed to other networks. Any changes in those other networks are rebased on top of the baseline and deployed via Bamboo.

The biggest flaw with this strategy for us is that it requires manual configuration of all of the various events within ScriptRunner (Listeners, Jobs, Endpoints, etc) based on only a readme file. We've looked into Script Plugins, but the inherent need to implement an Atlassian plugin environment seems to be a non-starter in air gapped environments due to the use of Maven, which would not be able to access the internet. Worse, IntelliJ is not an option for us, so any IDE solution would have to be done in another IDE (most of the company uses Eclipse). An IDE development environment is very lucrative for us (most of us have many gripes with the web editor), but we don't really see a path forward for it.

Current Idea

The team has recently been batting around ideas to improve on our current solution, and someone pitched the idea of writing a custom endpoint which could be called as part of our Bamboo deployment which would automatically configure ScriptRunner, allowing us to replace our readme file with some JSON/YAML/whatever which describes the configuration to create. Eg, the process would look like:

1. Copy baseline from development network to production network.
2. Rebase production branch on top of baseline.
3. Deploy with Bamboo, which will automate:
   1. Copying all groovy scripts to ScriptRunner's scripts folder.
   2. Calling the custom endpoint to update all listeners, jobs, etc (the endpoint would be manually configured once on each network, and the automation would take it from there)

Questions

So, with all of that background, I have two main questions:

1. Are we missing something/is this a stupid way of doing things? It certainly feels like reinventing the wheel, but we just don't see how we could realistically make Script Plugins work without making it very difficult to make changes on air gapped networks.
2. Under the assumption that this is a reasonable way forward given our constraints, how would I go about injecting new listeners/jobs/etc into ScriptRunner? If I wanted to, for example, use a groovy script to programmatically create a new custom listener which calls a given script, how would I do that? What about getting/removing the currently existing listeners?

[Miranda]

@Michael Wells Did this solution end up working for you? I'm kind of in the same boat as you are and wondering how to set up scriptrunner to function in an airgapped environment. 

[Michael Wells]

Yeah, it was a bit of a pain to set up, but ended up working out well. We also put some effort into getting Eclipse set up as a development environment using Groovy Development Tools and importing all of the various internal ScriptRunner/Jira/Bamboo jar files into the workspace. This turned out to be a much better development environment than the web IDE that comes with ScriptRunner, especially combined with the automated deployment strategy described above.