If sourcecode is managed on multiple JAZZ servers, wouldnt it be handy to be able to configure 1...n servers for a job (or globally) to fetch the code?

      The situation: code on Server A builds and provides libraries for Code on Server B, the code on Server B needs the code from Server A but cannot access it directly.

      Therefor when running a Job that compiles the code on Server B, one would need to fetch/pull/integrate/link/update the code from Server A as well.

      I can think of a "pre job" (or multiple of them) which all override the default server with Server A, Server B, ... and afterwards have a central job executed that works on the code. But this introduces inter-job dependencies one would like to avoid.

      Is this seen as a valid usecase and therefor an improvement? Is this maybe not thinking in JAZZ ways and therefor an abstruse setup? Input/Feedback is highly appreciated!

          [JENKINS-21477] Enable multiple Jazz servers per project

          I don't have any easy answers for you. It does sound like you need a job that builds the code from Server A and then a job that builds the code from Server B on top of it. It does introduce a dependency in jobs, but it simply reflects the dependency already there.

          If you wanted everything built only in 1 job, then you would need to do scripting to accept & load the code from Server A (using CLI), but this would not give you much in terms of traceability in the build to know what changed in the build from Server A. It would also be harder to reproduce a build unless you also start creating snapshots on Server A too. Which would mean you pretty much replicate in the CLI what a dependent job would do. It also means that changes on Server A would not result in triggering the build of B to occur either.

          Another option would be to use distributed SCM. That would mean the build workspace on Server B would pull components from 2 different streams (one on Server A and one on Server B). This means that states of the code on Server A would be replicated on Server B. The snapshot would contain every component so you have reproducability and traceability. We would need to make a change to the Plugin though to support the multiple credentials.

          Having us support multiple build workspaces would be interesting but I am not sure it would be in our immediate plans when multiple jobs or distributed SCM could do it.

          Heather Fraser-Dube added a comment - I don't have any easy answers for you. It does sound like you need a job that builds the code from Server A and then a job that builds the code from Server B on top of it. It does introduce a dependency in jobs, but it simply reflects the dependency already there. If you wanted everything built only in 1 job, then you would need to do scripting to accept & load the code from Server A (using CLI), but this would not give you much in terms of traceability in the build to know what changed in the build from Server A. It would also be harder to reproduce a build unless you also start creating snapshots on Server A too. Which would mean you pretty much replicate in the CLI what a dependent job would do. It also means that changes on Server A would not result in triggering the build of B to occur either. Another option would be to use distributed SCM. That would mean the build workspace on Server B would pull components from 2 different streams (one on Server A and one on Server B). This means that states of the code on Server A would be replicated on Server B. The snapshot would contain every component so you have reproducability and traceability. We would need to make a change to the Plugin though to support the multiple credentials. Having us support multiple build workspaces would be interesting but I am not sure it would be in our immediate plans when multiple jobs or distributed SCM could do it.

          x29a added a comment -

          Hi there and thanks for your comment.

          The problem with my scenario is, that Server A and Server B cannot communicate with each other, only the Jenkins instance has access to both.

          I do understand that working around this special case is not the job of a SCM plugin, but i do see more situations in which the described functionality could be useful. But i also understand that this is somewhat unimportant in relation to other tasks for your team.

          Anyway, i think the only solution for me right now is to use multiple jobs (maybe there is a plugin that can work around the hardcoded dependencies). Maybe, in the far future, this plugin will handle this case for me.

          x29a added a comment - Hi there and thanks for your comment. The problem with my scenario is, that Server A and Server B cannot communicate with each other, only the Jenkins instance has access to both. I do understand that working around this special case is not the job of a SCM plugin, but i do see more situations in which the described functionality could be useful. But i also understand that this is somewhat unimportant in relation to other tasks for your team. Anyway, i think the only solution for me right now is to use multiple jobs (maybe there is a plugin that can work around the hardcoded dependencies). Maybe, in the far future, this plugin will handle this case for me.

          Thanks for the details.

          I've raised an enhancement request for this so that it is tracked in both places.
          300164: Enable multiple Jazz servers per project

          Heather Fraser-Dube added a comment - Thanks for the details. I've raised an enhancement request for this so that it is tracked in both places. 300164: Enable multiple Jazz servers per project

          x29a added a comment -

          Maybe one could try to solve this with something like https://wiki.jenkins-ci.org/display/JENKINS/Multiple+SCMs+Plugin - although i think an "onboard" solution from within the RTC plugin would be the cleanest

          x29a added a comment - Maybe one could try to solve this with something like https://wiki.jenkins-ci.org/display/JENKINS/Multiple+SCMs+Plugin - although i think an "onboard" solution from within the RTC plugin would be the cleanest

          This scenario will be supported in the Workflow jobs. The new workflow project can be used to check out code from multiple Jazz servers using the RTC Scm with override. Would this be sufficient? We may not support this functionality for a FreeStyle job.

          Krishna Kishore added a comment - This scenario will be supported in the Workflow jobs. The new workflow project can be used to check out code from multiple Jazz servers using the RTC Scm with override. Would this be sufficient? We may not support this functionality for a FreeStyle job.

            clkkishore Krishna Kishore
            x29a x29a
            Votes:
            2 Vote for this issue
            Watchers:
            4 Start watching this issue

              Created:
              Updated: