Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root


1 badge earned


Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!


Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.


Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!


Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
Community Members
Community Events
Community Groups

Is there a way to have scriptrunner reliably update dependent classes?

We have quite a few scriptrunner items that pull in lists of data to function, one example is we have a table that maps our products to the development team associated with it.  This mapping list shows up in several places; post-functions, listeners, scripted fields, etc... To make updates easier and less prone to mistakes, I moved it to a class (in scripts/Classes).  The problem we are encountering is that updates to the class file are not picked up unless we issue a groovy class/cache reset... which has a domino effect of breaking the custom JQL functions we have loaded, requiring a re-scan.... which breaks some filters, which breaks dashboards, etc.  It can be quite clumsy.

This is mentioned in the documentation, but is there any way to avoid it?  Some super secret handshake or clever trick to assure that changes to a dependent class like the one I mentioned are picked up immediately?

2 answers

1 accepted

1 vote
Answer accepted

I tend to just clear the groovy cache as I don't have the same JQL dependency you describe.

But frequent change to a class file should only happen in a dev/test environment where you shouldn't care about this dependency, and only when doing the final deployment to prod would you need to rescan your JQL.

Maybe someone has a better way ... but if you're willing to give up on some performance, at least in your dev environment, you could always load your class dynamically like this:

import com.atlassian.jira.component.ComponentAccessor
import com.atlassian.jira.config.util.JiraHome

jiraHome = ComponentAccessor.getComponent(JiraHome).home
Class YourClass = new GroovyClassLoader(getClass().classLoader).parseClass(new File("$jiraHome/scripts/path/to/YourClass.groovy"))

But that's not suitable for a production environment since the class has to be loaded and compiled each time you use it.

Well, for our purposes, it might work.  If this call 'sticks', i.e. it will refresh the class in the main cache, then we could call this if, and only if, there's an update to the class... maybe add something to the built-in scripts so it can be a one-click operation.  I've been attempting this recently, but hadn't managed to figure out the syntax...  time wasted had I checked this thread earlier!


This particular snippet doesn't refresh the cache.

In you have another script somewhere else that calls the class you just updated, it will still be the old version of the class unless you refresh the cache using the built-in script.

The above simply loads the class from file with each execution without caching it.

If you want to dynamically clear the cache, you can add these lines to your script:

import com.onresolve.scriptrunner.canned.jira.admin.JiraClearCaches
new JiraClearCaches().doScript(["FIELD_WHICH_CACHE":"gcl"])
Like Ilya Turov likes this

What I am targeting is to clear/refresh the cache only for the updated class.  So, if I updated Classes/MyCustomFields.class  I can run/do something that does a persistent, targeted refresh of MyCustomFields only so the rest of the system can see the updates.

Curiously enough, it appears that the 'Preview' button when testing a Scripted Field does this.  If you test a given scripted field, it seems to trigger a full file reload and re-caching of any dependent classes.  And (as an added bonus) it somehow clears up whatever fault 'broke' the auto-refresh when an edit to a dependent class file occurs.... so there's no longer any need to fuss with anything as the class is updated as soon as you edit the class's file.

I have to look into what's going on here... I am not a 'pay no attention to the man behind the curtain' kind of person so I need to investigate what about 'Preview' makes it the great cure-all.  And I want to try to figure out what caused the auto-recache to stop working in the first place.

Yeah, you'd have to dig into the scriptrunner caching mechanism to figure out how to reload just a single class.

@Peter-Dave Sheehan 

import com.onresolve.scriptrunner.canned.jira.admin.JiraClearCaches
new JiraClearCaches().doScript(["FIELD_WHICH_CACHE":"gcl"])

Getting an error:

Could not find matching constructor for: com.onresolve.scriptrunner.canned.jira.admin.JiraClearCaches()

I am searching a way to do this groovy class loader cache clear via script in Scriptrunner.

Here is the new method for getting and executing a built-in script:

import com.onresolve.scriptrunner.canned.jira.admin.JiraClearCaches
import com.onresolve.scriptrunner.runner.ScriptRunnerImpl
def clearCaches = ScriptRunnerImpl.scriptRunner.createBean(JiraClearCaches)

@Corey Leighton Hi? did you find working method?

@Ilya Stekolnikov I haven't, but I haven't tried the new method mentioned in the post from 2-23-2022 yet either.  But even if it does, it wouldn't be 'automatic' in the sense that changes would still require the additional additional step of reloading the cache  when deploying script changes (so clicking 'clear cache' is in some respects just as easy). 

I did resolve the problem where a groovy refresh would break the custom JQL functions (it was related to a case mismatch in class names), so the groovy refresh isn't a rough operation, so that was a big improvement. 

At this point, I think the only full solution would require changes to how scriptrunner detects and reloads file changes.

Suggest an answer

Log in or Sign up to answer

Atlassian Community Events