com.onresolve.jira.groovy.groovyrunner - variables scope

[gil]

Have a question on he custom listener. When there is a trigger as a result of a change such as a new version added, I put in some groovy code to process something. From what I understand, I assume that each trigger will trigger the code to run. All he code variables and objects are local to get trigger section, meaning if there is a second trigger, all variables and object in this second session is local and unique within this / each session? The declared variable value in session 1 can’t be seen / modified in other trigger sessions?  And I assume that pass-in event object is local to each trigger call session?

[Nic Brough -Adaptavist-]

That is broadly correct.  A listener picks up events, and the events in Jira (which are triggered by activity of varying sorts) contain a pile of information about what triggered it.  They're independent of each other, so any given execution of a listener is based entirely on the data in its own event.

[gil]

Thank you for the prompt reply, Nic.  So I am experiencing some issue with the values obtained from the variable within a trigger session. 

Basically, in the ScriptRunner custom listener, I get the JIRA version information (version name and its JIRA project key) from the event object triggered from a version creation from a JIRA project, and then create a new version in a separate JIRA project based on the obtained key/version.  Everything is working fine, but at times, especially when there are concurrent, multiple creation of the JIRA versions, I got the incorrect key and version name and thus the wrong result.  I suspect that the defined variables within each trigger session are not local, i.e. they could be static variable and thus being used in other trigger sessions.  Below is a partial, sample code:

String sKey = event.version.projectObject.key;
String sVersion = event.version.name;
VersionManager vm = ComponentAccessor.getVersionManager();

if (event instanceof VersionCreateEvent){
  try{
    vm.createVersion(sKey + "-" + sVersion, null, null, 100101 ,null);

  }
  catch (Exception e) {

  }
}

[gil]

I just ran couple more testing.  In some cases, look like the version creation event is not even fired.  As a result, the version creation is not captured and hence not added to the other project.

To sum up the issue - the problems are 1). wrong values received; 2). the triggers come with same value set which shouldn't be; 3). no trigger on certain events.

[Aidan Derossett [Adaptavist]]

Hey Gil!

ScriptRunner actually has a built-in listener specifically for this functionality. Have you tried testing with the Version Synchronizer listener to see if the same problem seems to be occurring? 

Aidan

[gil]

We are using ScriptRunner version 4.1.3.24 for JIRA 6.x.  I think Version Synchronizer is only available in later version.

[Jamie Echlin _ScriptRunner - The Adaptavist Group_]

There is definitely nothing shared...

>  I got the incorrect key and version name and thus the wrong result.

How do you know it's incorrect... is it from an create version event that has already been processed?

[gil]

Hi Jamie - Let me explain the environment/scenario.  For this test, I try to stimulate the load test by, having 2 scripts to load the versions into JIRA project A and project B.  Then in turn, for each version created in A & B, it is created in project C via the listener.  Here is what I notice:

1). In a test, I notice that version1 is created in project A and project B.  Then version1 from A is created in also created in project C, but version 1 from B is not created in project C.  Note that I do add prefix to each version by using the JIRA project key so that there's no duplication in project C.  I put some code at the beginning of the trigger session before any processing to output what's received, and i this case, I don't see the version1 created from project B.

2). Similar to test 1, in this case, I get a duplicated version1, meaning I got 2 versions from the trigger - PRJA / version1 and PRJA / version1 instead of PRJB / version1.  So this is a case of duplication.

Again, please note that the creation of version1 in project C is made inside the trigger session - see code above.  I am wondering if that's causing an issue.

[gil]

To debug, I just made the script to read some event properties:

import com.atlassian.jira.event.project.VersionCreateEvent;
import com.atlassian.jira.project.version.Version;
import com.atlassian.jira.project.version.VersionManager;

System.out.println(event.version.projectObject.key + " | " + event.version.name);

What I found was, in one case, duplicated key | name is found instead of each unique set.  In another case, 3 sets of key | version are returned instead of 2 (as I create 1 version in project A and 1 in project B, hence 2 are expected).  The custom listener setup is to capture events from all JIRA projects, and event type is VersionCreatedEvent, VersionUpdatedEvent and VersionDeletedEvent.

[adammarkham]

If your creating versions in the code of one of your listeners using VersionManager and then listening for the VersionCreatedEvent then the listener will be triggered again for that version you've just created.

I think your statement below is correct and explains some of what you're seeing:

Again, please note that the creation of version1 in project C is made inside the trigger session - see code above.  I am wondering if that's causing an issue.

It's probably the listener being re-triggered by creating the new version inside your listener that's causing this. Same principle applies to version updates and deletes.

[gil]

I have tried to remove the version creation code inside the trigger and the issue remains — see the debug note I made above.

[Nic Brough -Adaptavist-]

That is broadly correct.  A listener picks up "events", and the events in Jira (which are triggered by activity of varying sorts) contain a pile of information about what triggered it.  They're independent of each other, so any given execution of a listener is based entirely on the data in its own event.