Checkout multiple git repos into same Jenkins workspace
GitJenkinsGit Problem Overview
Using Jenkins 1.501 and Jenkins Git plugin 1.1.26
I have 3 different git repos each with multiple projects.
Now I need to checkout all projects from the 3 git repos into the same workspace on a Jenkins slave. I have defined each git repo in: Source code Management: Multiple SCMs. But each time a repo is checked out the previous repo (and its associated projects) is deleted.
I have read this:
http://jenkins.361315.n4.nabble.com/multiple-git-repos-in-one-job-td4633300.html
but its does not really help. I have tried to specify the same folder under Local subdirectory for repo (optional) for all repos but it gives the same result.
If this is simply impossible using Jenkins I guess some pre-build step/scripting could be used to move the projects into the right location. Its not an option to modify the build configuration of the projects.
Git Solutions
Solution 1 - Git
With the Multiple SCMs Plugin:
-
create a different repository entry for each repository you need to checkout (main project or dependancy project.
-
for each project, in the "advanced" menu (the second "advanced" menu, there are two buttons labeled "advanced" for each repository), find the "Local subdirectory for repo (optional)" textfield. You can specify there the subdirectory in the "workspace" directory where you want to copy the project to. You could map the filesystem of my development computer.
The "second advanced menu" doesn't exist anymore, instead what needs to be done is use the "Add" button (on the "Additional Behaviours" section), and choose "Check out to a sub-directory"
- if you are using ant, as now the build.xml file with the build targets in not in the root directory of the workspace but in a subdirectory, you have to reflect that in the "Invoke Ant" configuration. To do that, in "Invoke ant", press "Advanced" and fill the "Build file" input text, including the name of the subdirectory where the build.xml is located.
Hope that helps.
Solution 2 - Git
Checking out more than one repo at a time in a single workspace is not possible with Jenkins + Git Plugin.
As a workaround, you can either have multiple upstream jobs which checkout a single repo each and then copy to your final project workspace (Problematic on a number of levels), or you can set up a shell scripting step which checks out each needed repo to the job workspace at build time.
Previously the Multiple SCM plugin could help with this issue but it is now deprecated. From the Multiple SCM plugin page: "Users should migrate to https://wiki.jenkins-ci.org/display/JENKINS/Pipeline+Plugin . Pipeline offers a better way of checking out of multiple SCMs, and is supported by the Jenkins core development team."
Solution 3 - Git
Since Multiple SCMs Plugin is deprecated.
With Jenkins Pipeline its possible to checkout multiple git repos and after building it using gradle
node {
def gradleHome
stage('Prepare/Checkout') { // for display purposes
git branch: 'develop', url: 'https://github.com/WtfJoke/Any.git'
dir('a-child-repo') {
git branch: 'develop', url: 'https://github.com/WtfJoke/AnyChild.git'
}
env.JAVA_HOME="${tool 'JDK8'}"
env.PATH="${env.JAVA_HOME}/bin:${env.PATH}" // set java home in jdk environment
gradleHome = tool '3.4.1'
}
stage('Build') {
// Run the gradle build
if (isUnix()) {
sh "'${gradleHome}/bin/gradle' clean build"
} else {
bat(/"${gradleHome}\bin\gradle" clean build/)
}
}
}
You might want to consider using git submodules instead of a custom pipeline like this.
Solution 4 - Git
I used the Multiple SCMs Plugin in conjunction with the Git Plugin successfully with Jenkins.
Solution 5 - Git
Jenkins: Multiple SCM - deprecated. GIT Plugin - doesn't work for multiple repos.
Scripting / pipeline as code - is the way to go.
Solution 6 - Git
Depending upon the relationships of the repositories, another approach is to add the other repository (repositories) as a git submodules to one of the repositories. A git submodule is creates a reference to the other repos. Those submodule repos are not cloned unless the you specify the --recursive
flag when cloning the "superproject" (official term).
Here's the command to add a submodule into the current project:
git submodule add <repository URI path to clone>
We are using Jenkins v1.645 and the git SCM will out-of-the-box do a recursive clone for superprojects. Voila you get the superproject files and all the dependent (submodule) repo files in their own respective directories in the same Jenkins job workspace.
Not vouching that this is the correct approach rather it's an approach.
Solution 7 - Git
I also had this problem. I solved it using Trigger/call builds on other projects. For each repository I call the downstream project using parameters.
Main project:
This project is parameterized
String Parameters: PREFIX, MARKETNAME, BRANCH, TAG
Use Custom workspace: ${PREFIX}/${MARKETNAME}
Source code management: None
Then for each repository I call a downstream project like this:
Trigger/call builds on other projects:
Projects to build: Linux-Tag-Checkout
Current Build Parameters
Predefined Parameters: REPOSITORY=<name>
Downstream project: Linux-Tag-Checkout:
This project is parameterized
String Parameters: PREFIX, MARKETNAME, REPOSITORY, BRANCH, TAG
Use Custom workspace:${PREFIX}/${MARKETNAME}/${REPOSITORY}-${BRANCH}
Source code management: Git
git@<host>:${REPOSITORY}
refspec: +refs/tags/${TAG}:refs/remotes/origin/tags/${TAG}
Branch Specifier: */tags/${TAG}
Solution 8 - Git
We are using git-repo to manage our multiple GIT repositories. There is also a Jenkins Repo plugin that allows to checkout all or part of the repositories managed by git-repo to the same Jenkins job workspace.
Solution 9 - Git
Checking out more than one repo at a time in a single workspace is possible with Jenkins + Git Plugin (maybe only in more recent versions?).
In section "Source-Code-Management", do not select "Git", but "Multiple SCMs" and add several git repositories.
Be sure that in all but one you add as an "Additional behavior" the action "Check out to a sub-directory" and specify an individual subdirectory.