Advanced GitHub (multi-project) to JIRA (single-project)

General Questions
, , ,
1

Originally asked by Geert van Horrik on 02 October 2019 (original question)

I would like to synchronize all our open source projects to an internal Jira issue tracker. I think this is actually a very common use-case. The first thing I tried was creating a 1 on 1 relationship per source repository(about 60). But then I found out that, in order to sync the status back to GitHub, I needed this per connection :

//If the jira status is Done, set the GitHub issue status to Closed
if(replica.status.name == "Done"){
 replica.status.name = "closed"
 issue.status = replica.status
}else{
 replica.status.name = "open"
 issue.status = replica.status
}

I am not going to fix this 60 times, just to find out that I might need to make other improvements in the future. So my next idea, back to the drawing board. I would like to have something like this:

Sync to JIRA

  1. (GITHUB) For all public repositories starting with ā€œOrcā€, I would like to sync (single connection if possible)
  2. (JIRA) Accept the invitation, then force the project key and remap the component:
 issue.projectKey   = "MyProjectKey"
   issue.components   += nodeHelper.getProject(issue.projectKey).components.find {c-> c.name == issue.project.name.replace("orc.", "").replace("orch", "")}

3. (JIRA) If the component cannot be found, stop syncing(but canā€™t find in the docs on how to accomplish this)

Sync back to GitHub

To sync back to GitHub, I would need to set up the status based on this example:

//If the jira status is Done, set the GitHub issue status to Closed
if(replica.status.name == "Done"){
 replica.status.name = "closed"
 issue.status = replica.status
}else{
 replica.status.name = "open"
 issue.status = replica.status
}

I am assuming Exalate knows to what project it needs to sync back to?

Would like to have any points on how to cancel syncing and whether itā€™s possible to put this all into a single connection.

2

Answer by Francis Martens (Exalate) on 03 October 2019

Hi Geert

It is a common use case to sync all the repositories of a single organization.
We are aware of it, this feature is fighting a number of other features on the priority front

(The same applies for hp ALM/QC domains and projects)

Regarding your questions

I am assuming Exalate knows to what project it needs to sync back to?

Yes, it does. The sync is done over a connection.

Would like to have any points on how to cancel syncing and whether itā€™s possible to put this all into a single connection.

You can cancel the sync by returning an empty replica in the outgoing sync.

Something like

def shouldSync = ...
if (!shouldSync) 
   return

...

Will ensure that the sync doesnā€™t happen.
Note however we do have a regression where the sync is happening, even when empty. I will need to confirm when this is going to be fixed.

Comments:

Geert van Horrik commented on 03 October 2019

> Yes, it does. The sync is done over a connection.

Even when I sync multiple projects over a single connect? The reason I would like a single connection is improved manageability (otherwise I have to go through all 60 connections every time I want to make a change).

Francis Martens (Exalate) commented on 03 October 2019

There are 2 routes here

  • modification of the product such that it can access all repositories of the product
    This is something to be investigated and will take some time to get it done.
  • Externalisation of your script
    Scripts can be externalized - meaning - the scripts can reside on an external folder and then called from the connections (check here for more details). You can then construct a class / method which centralizes all the logic. This method can then be called from your connection.

Given that the githubnode is running on our servers, we need to find a way to ā€˜mountā€™ an external folder onto your scripts folder, or provide a way to git clone your scripts repo onto your environment.

A bit of a head-scratcher - all help is welcome.

Geert van Horrik commented on 03 October 2019

>> Given that the githubnode is running on our servers, we need to find a way to ā€˜mountā€™ an external folder onto your scripts folder, or provide a way to git clone your scripts repo onto your environment.

Support loading gists (since itā€™s github anyway)? Obviously itā€™s up to the caller if they want to include gists they have no control about (security risk), but I think that could totally work. Then you ā€œonlyā€ have to implement downloading a raw gist (for now with the same credentials you are using to access the repositories).

Geert van Horrik commented on 03 October 2019

btw checking out the docs, it only talks about Jira server. Loading custom scripts is not available on Jira cloud?

Geert van Horrik commented on 03 October 2019

Iā€™ve taken the time just to update them all manually on the github incoming sync connection side.

Francis Martens (Exalate) commented on 03 October 2019

It is available for all ā€˜on-premiseā€™ platforms such as hp alm/qc, bmc remedy, Jira on premise and so on.

On Jira cloud, we do deploy a number of our scripts but donā€™t allow for custom externalized scripts atm.

Gists might work or maybe grab. something like

@Grab(group='acme', module='gitmigration', version='1.0.0-RC1')
import com.acme.exalate.PreepareMigration

replica = PrepareMigration.send(issue)

The development cycle would be

  • Develop the logic using the inline scripts
  • Commit to some maven repo / artifactory / nexus
  • Adapt all connections to use the PrepareMigration.send