Had some issues with Jenkins when trying to checkout a project with Git nested submodules. It failed with a permission error when cloning the submodules:
hudson.plugins.git.GitException: Command "git submodule update --init --recursive some/path" returned status code 128:
stdout: Submodule path 'some/path': checked out '34e663c11661b5153076c1d624ead25137df0783'
stderr: Cloning into 'some/other/path'...
Host key verification failed.
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.
fatal: clone of '[email protected]:foo/foo.git' into submodule path 'some/other/path' failed
Failed to recurse into submodule path 'some/path'
In the Jenkins job, checking out submodules is enabled:
In the Git plugin under Advanced sub-modules behaviours
, the options Recursively update submodules
and Use credentials from default remote of parent repository
are enabled.
All git repositories are private Github repositories, but the Jenkins user has read access to them.
The only way to get it working as by replacing git@...
URLs by https://...
. For instance, this here would fail
[submodule "foo"]
path = some/path
url = [email protected]:foo/foo.git
... but this would work
[submodule "foo"]
path = some/path
url = https://github.com/foo/foo.git
I cannot rule out that there is a misconfiguration on our end. But still I have some generic understanding question:
- Does the Jenkins Git plugin support
git@
URLs? Or is it a known limitation that you need to usehttps://...
URLs? - Why does the choice of the protocol make a difference on Jenkins? Is it because
git@
assumes that SSH keys of Jenkins were added to the Github repository?