|
||||||||
|
This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira |
||||||||
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
My workaround for this issue has been to do the initial clone and submodule update from a command shell on the server. This works great and doesn't prompt for any authentication because it's using certificates. The submodule ("Cinder") is rather large and has several submodules within it. Cloning it definitely takes longer than ten minutes, so the timeout isn't entirely surprising. (It is a fork of this: https://github.com/cinder/Cinder/tree/dev)
So, I don't think it's blocking on an authentication prompt, both because it works fine from the command line, and also because the parent repo and the submodule both have the same authentication, and the parent works fine. Also when either the parent or submodule are updated, Jenkins gets those updates reliably. It's just the initial clone that's a problem.
If there's another way I can confirm, let me know, and thanks for your help.