Jess Thompson
18th March, 2021
Jira
Version control and custom scripts in ScriptRunner's Script Registry
Find out how you can manage your ScriptRunner for Jira scripts in line with DevOps best practice and achieve version control using new Script Registry features.
Script Registry is a feature of ScriptRunner for Jira that doesn’t get too much love. We tend to focus on snazzier and more ‘exciting’ features, but today we want to celebrate a powerhouse feature for organisation, testing and auditing.
A large chunk of ScriptRunner users have never used Script Registry, so if you’re already familiar with it, forgive us for a minute while we explain what it does, or skip to the updates.
Script Registry is a single place to view all of the groovy scripts used throughout your ScriptRunner instance at once. From this page you can see all of your ScriptRunner scripts in one place, making it especially useful if you have bulk changes you need to make, such as replacing API details. You can find everything that’s affected from a single screen.
To help you navigate around your scripts and find just what you’re looking for, everything is grouped by section according to the script functionality. Just tab across the top to find what you’re looking for.
From the Script Registry, Static Type Checking is also run automatically. This performs a check of the code to ensure that it is syntactically sound while also checking for common errors.
We’ve updated Script Registry
There are two ways to add scripts in ScriptRunner; either written directly into the Code Editor or uploaded as a file, and speaking with ScriptRunner users in the past, the preferred method has been to work directly in the code editor because everything that had been directly written into the system was visible, legible and could easily be searched using Cmd/Ctrl and F when viewed via the Script Registry.
Our latest update to Script Registry now extends this same searchable functionality to all scripts, whether they are written directly into the editor or uploaded via a file. Script Registry gives total visibility, expanding the contents of any uploaded file to show the code in full in the Script Editor window, making everything searchable and legible from a single screen.
Why might I prefer files?
The use of files can make it easier to modularise your scripts for swift updates. If the same script reappears within other scripts across your Jira instance, uploading these snippets via files makes updating the “shared” code in future a breeze. You can update your single file with the confidence that all scripts which rely on that code to perform their function are good to go, rather than updating three -- or thirty -- scripts separately. Much quicker and more efficient and less prone to human error!
Further to this, while working directly in the code editor can certainly be convenient, it doesn’t allow for version control in line with DevOps best practice. If that’s something that’s important to your business, you may already have been using files to manage your scripts.
If not, and you’re keen to incorporate more DevOps best practice within your teams, using files for version control in ScriptRunner is recommended to give better traceability/auditing, and we’re delighted to say that there’s no longer an efficiency trade-off of being able to use Cmd/Ctrl F: it’s access all areas, whatever your approach.
Version Control
Quicker changes to custom scripts
So whichever method you prefer for inputting and storing your custom scripts, whenever you next have updates or changes to make to your Scripts, you can now head straight to your Script Registry to locate and navigate to the files/scripts you need to alter. Once you have made your required changes, the same Static Type Checking runs to confirm that everything looks good: all from a single screen.
If you’d like more inspiration for how ScriptRunner can help you achieve more development efficiency and encourage DevOps best practice, check out this case study from GAIN Capital (part of StoneX). It breaks down the simple process they used to get developer buy-in and compliance with internally-agreed code standards, and comes complete with free script examples for you to customise.