Status: Closed (View Workflow)
Resolution: Won't Fix
I have two repos namely - commonlib.git, project1.git, and both of the have the root directories Source and CM. My Jenkins job is MultiGit_Job. I tried to configure a Jenkins job with two repos. During build, the source code for the first project is extracted (found when monitoring during the build execution) and the job fails during the second repo cloning. When I have analyzed the job's workspace, the commonlib.git source is extracted directly under workspace. There is identifier for commonlib repo. Because project1 repo also same root structure, the cloning is failing. It is a critical item for us as we are migrating our projects to GIT now. Thanks
Pipeline is Groovy, which is easier than many scripting languages. If it's too complex for users, they probably need to find another industry.
As Pipeline is the way of the future with Jenkins, it is an acceptable solution to this problem to recommend Pipeline. With 2.x, Pipeline becomes part of the product (a core plugin). It's available as a plugin now. My team accepted there is no reason to put an enormous effort into 1.x functionality and has moved on to using Pipeline.
Since pipeline supports multiple git repositories, that is the preferred solution for this.
Supporting multiple repositories from inside the git plugin will introduce too many compatibility problems for the git plugin.
Yes, the pipeline script supports multiple git repositories to be checked out (cloned) into the corresponding the sub-directories.
But how should one write this script so that the polling of these repositories would trigger the job in case of updates? Please, see my question in details here: https://stackoverflow.com/questions/47439718/trigger-a-job-by-polling-multiple-git-repos-inside-jenkinsfile.
Pipelines are not usable as for now, because any triggers and parameters defined in them are ignored until you manually start the job.
I suspect job definition would require re-work to support multiple SCMs. It's not un-doable but no one has put forth effort to work on it. I think it's best to be a core Jenkins feature, and get the review necessary to support the workflow. I don't think it's too far out there, and I think even changes could be handled properly that way.
I think that this extension of features is worth doing even though pipelines support multiple repositories, as pipelines are more complex and not for everyone.