Jenkins produces fatal EOF while fetching a git repository

Question

We've switched from SVN to Git for our repositories which was rather uneventful. The only trouble we now have is that Jenkins refuses to fetch our new Git repositories. Our Git repositories are hosted on Atlassian Stash which is configured as a public readonly http repositories.

I've tried several things, but had no success. The Git repositories fetch properly using Source Tree and Visual Studio 2013.

Stash runs on a Windows 8 computer as a service under the 'Local system' user. I've tried configuring it to run under a local user account that has compression turned off (core.compression 0).

I've tried to use both C:\Program Files (x86)\Git\bin\git.exe and C:\Program Files (x86)\Git\cmd\git.exe.

The output that it produces is the following:

Receiving objects:  82% (19700/23879), 106.27 MiB | 6.00 KiB/s   
fatal: early EOF
fatal: The remote end hung up unexpectedly
fatal: index-pack failed
error: RPC failed; result=56, HTTP code = 200

    at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1442)
    at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:1230)
    at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.access$300(CliGitAPIImpl.java:85)
    at org.jenkinsci.plugins.gitclient.CliGitAPIImpl$1.execute(CliGitAPIImpl.java:280)
    at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:645)
    ... 10 more

Although I've tried with earlier versions of Jenkins and the GIT plugins, it also fails with the latest software versions, namely:

git version 1.9.4.msysgit.2
Jenkins 1.588
GIT client plugin 1.11.1
GIT plugin 2.2.7

Is it reproduced all the time at 82%? What version of Git plugin do you use on Jenkins? — Ostap Elyashevskyy, Nov 11 '14 at 14:04
It does not always stop at 82%, sometimes later and sometimes earlier. — Wouter, Nov 11 '14 at 14:14
Please check answer under the link, looks like it is index-pack related issue: http://stackoverflow.com/questions/10589498/git-getting-early-eof-error-on-clone — Ostap Elyashevskyy, Nov 11 '14 at 14:18
It seems none of those are related. I don't use the SSH protocol, I don't use Cygwin and the memory limit issues seem to only occur during the compression phase. — Wouter, Nov 11 '14 at 15:59
We did not have this problem for ages, but lately it seems to pop up again.. Still don't have a clue. — Wouter, Mar 20 '17 at 16:16

score 0 · Answer 1 · edited Jun 20 '20 at 09:12

0

You can try to avoid the index-pack by increasing your http buffer size:

git config --global http.postBuffer 1048576000

From the git-manual:

http.postBuffer

Maximum size in bytes of the buffer used by smart HTTP transports when POSTing data to the remote system. For requests larger than this buffer size, HTTP/1.1 and Transfer-Encoding: chunked is used to avoid creating a massive pack file locally. Default is 1 MiB, which is sufficient for most requests.

It seems counter-intuitive, but this often helps with clones and pulls.

edited Jun 20 '20 at 09:12

Community

1
1

answered Nov 11 '14 at 19:56

Michael

10,124
1
34
49

This is not something that can be configured in Stash, but can be set on individual repositories. I guess I should try Atlassian support. – Wouter Nov 12 '14 at 07:38
This is a git config not a Stash config (though I don't really know Stash), so you can set it globally. – Michael Nov 12 '14 at 15:55

Jenkins produces fatal EOF while fetching a git repository

1 Answers1