With the current Git plugin, you don't even need that.
The Git plugin supports repositories with submodules which in turn have submodules themselves.
This must be turned on though:
in Job Configuration -> Section Source Code Management, Git -> Advanced Button (under Branches to build) -> Recursively update submodules
But the OP is using pipeline.
So a simple first build step is enough:
git submodule update --init --recursive
However, the OP adds:
Yes but if I'm using sh 'git submodule update --init --recursive'
, this will use $HOME/id_rsa
right? I want to pass in my private key for this command if possible.
It is possible: In the Pipeline syntax, you can define environment variables.
Which means you can set GIT_SSH_COMMAND
(with Git 2.10+).
That allows you to reference your own private key.
pipeline {
agent any
environment {
GIT_SSH_COMMAND = 'ssh -i /path/to/my/private/key'
}
stages {
stage('Build') {
steps {
sh 'printenv'
sh 'git submodule update --init --recursive'
}
}
}
}
If any clone involve an ssh url, that ssh clone will use the right private key.
Note that sancelot points out in the comments:
unfortunately this does not work: JENKINS-38860
The error reported above:
FATAL: Command "git config --get submodule.MySubModule.url"
returned status code 1
Occurs for me whenever you have nested submodules.
Consider a scenario in which repo A
contains submodule B
, which contains submodule C
.
If "Advanced submodule behaviour
" with "Recursively update submodules
" is not enabled, Jenkins will clone A
, checkout/clone B
, and fail to initialise/clone C
.
This is probably expected behaviour.
If you enable "Recursively update submodules
", you get the error:
FATAL: Command "git config --get submodule.C.url"
returned status code 1