The https based failure to clone from github.com likely indicates that your company has a proxy configured and the proxy configuration was not used for the git clone command. A timeout trying to reach port 443 on the public internet most often means that the command line git program is unable to connect to the https port of the remote server and some network infrastructure (proxy, etc.) is intentionally blocking that connection. The ssh based failure might indicate that you didn't configure the job to use an ssh credential, or the ssh credential you configured is not registered with github.com, or the same network configuration that is blocking access to https on the public internet is also blocking ssh access to the public internet. The Jenkins git plugin supports two forms of credentials:
- username/password for https and http connections
- private key for ssh connections (g...@example.com:dir/repo.git and ssh://example.com/dir/repo.git)
I believe that I've used GitHub keys in the username/password case by creating a credential with MarkEWaite as the username and the deploy key as the password. You might try the same thing. Using the git plugin with a typical secured git server without using credentials is quite difficult. It requires that every agent be configured to login to the secured git server by default. It is possible to do that, but it tends to make the management of Jenkins agents much more difficult. I assumed you are using Jenkins credentials rather than attempting to configure each agent so that it can login to the secured git server without credentials. Are you using Jenkins credentials? |