I have 4 git repos in my setup, hosted on Bitbucket and accessed over SSH. I updated to 1.9.0.143 today. Since then, I have been unable to check or reset one of the repos. The other 3 repos are accessed in exactly the same way, with the same SSH key, and are working perfectly. There are two recurring errors in the event logs:
Repository XXX cannot be initialised: Running ‘C:\Program Files\Git\cmd\git.exe’ with arguments “clone --no-checkout --progress *********************************************** C:\Users\ContinuaCI\ShareRoot\Rc\2149f40f” failed and threw exception: “Access is denied”
Repository XXX cannot be initialised: Running ‘C:\Program Files\Git\cmd\git.exe’ with arguments “clone --no-checkout --progress *********************************************** C:\Users\ContinuaCI\ShareRoot\Rc\2149f40f” failed with return code -1 and error output: “The process timed out as there was no response for 20s 0ms. Process was running for 21s 364ms in total.”
This is a large repo - it is possible that a new 20s timeout has been introduced?
Can you help me to interpret the ‘access denied’ message? What is this referring to? SSH access to the repo using the installed keys is working fine via git bash when logged in to Windows as the Continua user.
The Access is denied message is coming directly from the git command line. The 20 second timeout occurs only if there has been no output from the git command line for 20 seconds. This is usually because the git command line is prompting for input.
Can you try running the same git command in command prompt? e.g.
while logged in as the Continua service user and let us know what the output is.
Can you also let us know the format of your ssh url e.g. * user@host.xz:port/path/to/repo.git or ssh://user@host.xz:port/path/to/repo.git or git://host.xz/path/to/repo.git, and the version of the git command line that you are running.
If I run the command manually via command prompt, logged in as the Continua user, it clones the repo as expected. It takes a few minutes as the transfer is ~400MB after compression. After a bit of retrying, this seems to have got it working, for now anyway.
Was there a long delay before there was any output from the clone command? If so, approximately how long? We may need to make the timeout configurable.
What I should have asked is whether there was any interval longer than 20 seconds where there was no output to the console?
I’ve done some testing cloning various large git repositories using version 2.8.1.windows.1 of Git for Windows and haven’t been able to reproduce a scenario where progress output pauses for more than a couple of seconds and causes a timeout. I guess however that network connectivity issues could cause a longer delay, so we have added the ability to change the timeout for the next version of Continua CI.
Meanwhile let us know if you encounter any further errors.
Note the latest version of Git for Windows is currently 2.21.0.windows.1
I did a bit more testing and saw some delays approaching 20s at the ‘counting objects’ stage. Perhaps if the remote was busy this could take longer; I’m guessing that stage is not network bandwidth limited. The progress reporting on the compression and transfer would normally prevent it getting to 20s without any output I think, unless it was a really huge transfer or very slow.
Potentially a lifesaver to have a configurable timeout; thanks!
Version number was an early-morning typo, I have the latest version now.
I encountered this problem again and can confirm that there was a period of more than 20s without output to the console, in this case during the ‘unpacking objects’ phase, when running: