How to archive a big number of issues and possible automation rule

[Adrian Popescu]

Hello,

I'm dealing with an instance which has a big database of issues. In order to improve performance, indexing, etc., I would like to archive issues that were last updated the earliest 2 years ago. 

After running a simple jql for that: Updated <= startOfMonth(-24) and statusCategory = Done ORDER BY updated DESC , I'm left with more than 700k issues which will have to be archived. (Deleting is not an option sadly as the company wants to have the possibility of reactivating some of the issues if necessary)

Currently I'm looking into a way of doing this with Jira Automation plugin or Scriptrunner, in order to also create an automation rule for future usage and I'm not feeling so lucky just yet. Sadly for scriptrunner I don't have the coding experience and didn't find any script already used by someone.

The other option is exporting all those issues to a separate jira instance which will be used only for archiving, but I would like to leave that as a 2nd option and first focus on the possibility of archiving in the current instance.

Did anyone have an experience with something like this? If yes, how did you deal with it (if you can provide the solution)?

I would appreciate any help if possible.

Thank you!

[Lady Di · Accepted solution]

Hi, you can use the plugin MyGroovy

Use the module

Scheduled tasks

to run the script periodically on a specific JQL

import com.atlassian.jira.component.ComponentAccessor
import com.atlassian.jira.issue.archiving.ArchivedIssueService

@StandardModule
ArchivedIssueService a

def authContext = ComponentAccessor.getJiraAuthenticationContext()
//issue = ComponentAccessor.getIssueManager().getIssueObject("TESTISSUE-1234")
def validationResult = a.validateArchiveIssue(authContext.getLoggedInUser(), issue.getKey());
if (validationResult.isValid()) {
a.archiveIssue(validationResult);
}

[Adrian Popescu]

Hello @Lady Di

Thank you for the suggestion, but currently due to the high number of already existing plugins, I wouldn't like to add more to the list and try to deal with the issue with what's currently installed. If nothing else works, I'll probably consider installing it, although it looks like the support version for it is only for server and we're running a Data Center version of JIRA.

Thank you!

[Lady Di]

We write it for our own needs and use it on Jira DataCenter too (5+mln issues, 4 nodes)and actively share our work with the community. The plugin is open source (https://github.com/atlascommunity/jira-plugins-groovy)and completely free.

[Jess Seitz]

Hi @Adrian Popescu 

Wanted to share that we just released issue archiving in Jira Software Data Center 8.1, and a new browse archives page in 8.4. Here's our announcement and blog with all the details, including performance testing results showing a reduction in JQL searches, backlog loading, & re-indexing: 

https://community.atlassian.com/t5/Enterprise/Introducing-issue-archiving-it-s-time-for-some-Jira-spring/gpm-p/1177470

https://www.atlassian.com/blog/enterprise/issue-archiving

Cheers, 

Jess

[Adrian Popescu]

Hi @Jess Seitz 

Thanks for sharing!

I looked through it and although that is something useful, when talking about 800k+ issues to archive, using limited number bulk actions, won't help that much, leaving room for tons of manual work.

Cheers,

Adrian

[Jess Seitz]

That's good feedback @Adrian Popescu

With the next release (Jira 8.5) we are delivering an automation cookbook for archiving, with detailed documentation on how to automate this process. Will plan to share that here and with the community once that is live, and would love feedback. 

Best,

Jess

[Victor Seger]

Hello @Adrian Popescu ,

Unfortunately, we currently don't support this type of action on our plugin, as this is a new API on JIRA. 

We have already an issue for tracking the development of this feature, but it might take some time for us to implement, as we got higher priority tasks on our backlog at this moment (https://codebarrel.atlassian.net/browse/AUT-1444).

Sorry for not helping that much at this time.

Feel free to reach us in case of any further questions.

Cheers,

Victor - Automation for JIRA 

[Adrian Popescu]

Hello @Victor Seger ,

I understand, that's too bad as I was hoping I'll be able to deal with this more simple when I first started looking into it.

I do have one question though.. Is it possible to run the clone function on schedule with a jql? I was also thinking about the possiblity of cloning the issues (since move is not available) to another project, then delete the old issues and eventually just archive the whole project which will contain all the issues I was interested in archiving.

I ran a test on a test instance with scheduled jql then cloning action to the new project, but it doesn't seem to do anything and I'm being left with "No Actions Performed" status on it.

Any help on this one? It's also a possibility I was thinking about. Most likely not the fastest one, but could also do the trick if possible.

Thank you!

[Victor Seger]

Hi @Adrian Popescu ,

Yes, it is possible. But due to the high number of issues that your JQL query returned, it might be some throttling issues on your rule.

Although, can you please share with me a screenshot of your current rule? That way I will be able to advise you on how to make this work.

Thanks in advance!

Cheers,

Victor - Automation for JIRA

[Adrian Popescu]

I actually modified it first to test with a lower number of issues. Currently the JQL returns only around 800 issues.

Here's the screenshot. Currently I'm only running it manually for testing.

[Victor Seger]

@Adrian Popescu ,

Thanks for sharing this screenshot of your rule.

Can you please ensure that your rule doesn't have any project restrictions on the "Rule details" page under the "Restrict to Projects" field?

If there are any projects inserted on this field, can you please leave the field blank and see how the rule execution goes?

Cheers,

Victor

[Adrian Popescu]

My bad, totally forgot about automation rule project restrictions. It should go fine now.

Now time to test how many clones per run it will support and how long it will take.

[Victor Seger]

No problem, @Adrian Popescu !

Thanks for replying!

One thing that is important to do is go to your "Scheduled" trigger, under the "More options" section and select the "Process all issues produced by this trigger in bulk".

So your rule will execute faster, according to my tests here.

Let me know if you got any further questions!

Cheers,

Victor