How to track down a Jenkins failure to checkout git submodule over ssh?

StackOverflow https://stackoverflow.com/questions/22337098

Question

I'm using bitbucket and Jenkins to do my builds. My project has a submodule that needs to be checked out during the build process. The top level git repository that I'm using is working fine. It pulls that out of bitbucket using deployment keys with SSH access no problem. I have the same deployment key on both repositories. I also made my submodule defined relatively to my project:

[submodule "platform/web-app/WEB-INF/learning"]
    path = platform/web-app/WEB-INF/learning
    url = ./../xxxxxxxx.git

However, when Jenkins builds the project it pulls down the top level repository and fails during the submodule. Jenkins is building this using the EC2 plugin so it's built on a slave box that is started up on demand. I've tried to execute git manually on the box, but it fails the same way. I don't fully understand how the ssh key gets pushed onto the box, but I don't understand how to debug this. Why does this work for one module, but fails for the submodule?

Here is the output:

FATAL: Command "git submodule update --init --recursive" returned status code 1:
stdout: Cloning into 'platform/web-app/WEB-INF/learning'...

stderr: Permission denied (publickey).
fatal: Could not read from remote repository.

Please make sure you have the correct access rights and the repository exists.
Clone of 'git@bitbucket.org:xxxxxxxx/xxxxxxx.git' into submodule path 'platform/web-app/WEB-INF/learning' failed

hudson.plugins.git.GitException: Command "git submodule update --init --recursive" returned status code 1:

stdout: Cloning into 'platform/web-app/WEB-INF/learning'...

stderr: Permission denied (publickey).
fatal: Could not read from remote repository.

Please make sure you have the correct access rights and the repository exists.
Clone of 'git@bitbucket.org:xxxxxxxx/xxxxxx.git' into submodule path 'platform/web-app/WEB-INF/learning' failed

    at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1148)
    at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1125)
    at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1121)
    at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommand(CliGitAPIImpl.java:937)
    at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.submoduleUpdate(CliGitAPIImpl.java:598)
    at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.submoduleUpdate(CliGitAPIImpl.java:579)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:606)
    at hudson.remoting.RemoteInvocationHandler$RPCRequest.perform(RemoteInvocationHandler.java:299)
    at hudson.remoting.RemoteInvocationHandler$RPCRequest.call(RemoteInvocationHandler.java:280)
    at hudson.remoting.RemoteInvocationHandler$RPCRequest.call(RemoteInvocationHandler.java:239)
    at hudson.remoting.UserRequest.perform(UserRequest.java:118)
    at hudson.remoting.UserRequest.perform(UserRequest.java:48)
    at hudson.remoting.Request$2.run(Request.java:328)
    at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
    at java.util.concurrent.FutureTask.run(FutureTask.java:262)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
    at java.lang.Thread.run(Thread.java:744)
Was it helpful?

Solution

I think you're encountering the problem reported here: https://issues.jenkins-ci.org/browse/JENKINS-20941

From the symptoms I'm seeing, the credentials you put into Jenkins are used for checking out the top level repo, but they're not used when trying to get the submodule updates.

There are two angles for a workaround:

  • Put the key file(s) onto all your build slaves
  • Update your job configurations to update explicitly

Or you can just wait for the maintainers to fix it, or fix it yourself :-)

Hope this helps

OTHER TIPS

I'm using ssh-agent with specific credential in job configuration. Then in build step I have "Exec shell" component with:

git submodule init
git submodule sync
git submodule update --init --recursive
Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top