|
||||||||
|
This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira |
||||||||
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
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.