Is it possible to revert a scriptrunner script or see its history?

[William Frank Merlock]

I have a Scriptrunner script that was developed in the Script Editor window and resides in the default area (atlassian/jira-home/scripts).  The script is run periodically as a Job.

Is there any way to see the history of changes to the script, or to revert to previous changes, or to undo recent changes?

As a practice we will copy the script text, paste it into a file, and store that file in bitbucket, but this kind of manual process is fragile, and we have occasionally lost changes that didn't make it through that process properly.

[Nic Brough -Adaptavist- · Accepted solution]

Welcome to the Atlassian Community!

I am sorry, but no, there's no way to do this.  The scripts are held as a free text field in the database, and as a one-off, with no version control on them.  

We do have an improvement somewhere about enabling version control of some sort (probably not much more than "save a copy every time you edit a script along with date and author), I'll see if I can dig it out for your up-vote if you want.

You're already doing what Jamie and I always did - keep the scripts on the disk, under source control!  But I know that's a bit of a faff and prone to error.

[Nic Brough -Adaptavist-]

I think https://scriptrunner-for-jira-cloud.nolt.io/6 is closest to "source control in SR"

[William Frank Merlock]

Thanks for the answer!  All the answers posted today were very good, but I particularly appreciate the link to the feature-request up-vote.

Thanks again for your time!

[PD Sheehan · Accepted solution]

As others have said, there is no built in change history for inline scripts stored in the database. And unless your file system on the server has some form of built in history tracking, then you’re out of luck.  

But I think that any script with any level of complexity (say more than about 10 lines) can stand to be managed in some source code  repository. If you lock down your production environment and force all changes to first be commited to your repo, you can have full line by line visibility of the change history. As a bonus, you can then have a code review and deployment step to control what changes get introduced and when. 

[William Frank Merlock]

I agree with your last paragraph, and we do have a source code repository that we use to store most of our scripts.  We have a number of competing priorities, needs, wants, and use cases, so we've decided not to lock things down to the extent that we would need to in order to have 100% enforcement.  What we have mostly works for us, but as I mentioned in a response to a different post, if the tool were to add a history functionality, it would tidy things up nicely.

Thank you very much for taking the time to answer!

[Judah · Accepted solution]

You might be able to search your log files for entries that were made by ScriptRunner.

[William Frank Merlock]

Thank you! I will look into that.

[Radek Dostál · Accepted solution]

No, I don't think SR does versioning, it doesn't seem to have any tables for it either. Personally I keep a git repo for scripts, edit (mostly) in IDE, and sync changes back and forth when needed (manually in shell, wanted to automate this but never really finished the idea).

I'm guessing the main problem in your case is.. bad coding habit? It should be rather unusual to need to restore previous groovy scripts. I wrote probably over a thousand different things but I don't remember the need to ever rollback (if it's that complex of a script, then IDE keeps history, SR editor is just a basic thing that gets the job done, but it can't replace git/ide).

[William Frank Merlock]

I don't disagree, but I also believe that if you "automate everything" by having tools that simplify important processes, you can encourage good habits. In our environment, not every Scriptrunner script writer is a trained developer, so having the Script Console tool encourage (and enforce) good habits would be nice.

But again, you make a good point and this is something we are doing, albeit imperfectly.

Thanks for taking the time to answer!