1
0
-1

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.

    CommentAdd your comment...

    1 answer

    1.  
      1
      0
      -1

      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.



      1. Geert van Horrik

        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).

      2. user-3fd1a

        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.

      3. Geert van Horrik

        >> 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).

      4. Geert van Horrik

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

      5. Geert van Horrik

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

      6. user-3fd1a

        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



      CommentAdd your comment...