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 'firstname.lastname@example.org: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@example.com: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 use
- 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?