问题
All of my Jenkins builds are failing at the git fetch
line.
It's failing at git fetch --tags --progress git@bitbucket.org:ethenwilson/whentoact.git
Started by user anonymous
Building in workspace /Users/ethen/.jenkins/workspace/Build NikNik
> git rev-parse --is-inside-work-tree
Fetching changes from the remote Git repository
> git config remote.origin.url git@bitbucket.org:ethenwilson/whentoact.git
Fetching upstream changes from git@bitbucket.org:ethenwilson/whentoact.git
> git --version
using GIT_SSH to set credentials NikNik BitBucket SSH Key
> git fetch --tags --progress git@bitbucket.org:ethenwilson/whentoact.git +refs/heads/*:refs/remotes/origin/*
FATAL: Failed to fetch from git@bitbucket.org:ethenwilson/whentoact.git
hudson.plugins.git.GitException: Failed to fetch from git@bitbucket.org:ethenwilson/whentoact.git
at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:622)
at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:854)
at hudson.plugins.git.GitSCM.checkout(GitSCM.java:879)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1252)
at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:624)
at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:530)
at hudson.model.Run.execute(Run.java:1732)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
at hudson.model.ResourceController.execute(ResourceController.java:88)
at hudson.model.Executor.run(Executor.java:234)
Caused by: hudson.plugins.git.GitException: Command "git fetch --tags --progress git@bitbucket.org:ethenwilson/whentoact.git +refs/heads/*:refs/remotes/origin/*" returned status code 128:
stdout:
stderr: remote: Counting objects: 2682, done.[K
remote: Compressing objects: 0% (1/1399) [K
remote: Compressing objects: 1% (14/1399) [K
...
remote: Compressing objects: 99% (1398/1399) [K
remote: Compressing objects: 100% (1399/1399) [K
remote: Compressing objects: 100% (1399/1399), done.[K
Receiving objects: 0% (1/2682)
Receiving objects: 1% (27/2682)
...
Receiving objects: 78% (2092/2682), 4.07 MiB | 1.59 MiB/s
Corrupted MAC on input.
Disconnecting: Packet corrupt
fatal: The remote end hung up unexpectedly
fatal: early EOF
fatal: index-pack failed
at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1325)
at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:1186)
at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.access$200(CliGitAPIImpl.java:87)
at org.jenkinsci.plugins.gitclient.CliGitAPIImpl$1.execute(CliGitAPIImpl.java:257)
at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:620)
... 10 more
When I run git fetch --tags --progress git@bitbucket.org:ethenwilson/whentoact.git
from the command line, it works fine, which means my SSH keys must be working.
I'm connecting to BitBucket with Jenkins with SSH verification. Jenkins gets the key from the file it's located (the default one), so I know that Jenkins is using the same key as I am when I run from the command line.
I'm using the latest build of the BitBucket and Git plugins for Jenkins. My installed Git on my Mac is version 1.8.5.2 (Apple Git-48)
.
My jenkins start command is nohup java -jar ~/jenkins.war --httpPort=8081 --ajp13Port=8010 > /tmp/jenkins.log 2>&1 &
.
What's going wrong?
EDIT: I was wrong, I had accidentally hit an option to have the SSH Key be in the wrong place when I did that. Now, using @borrrden's suggestion, it still gives the same error. **EDIT: As @borrrden suggested, I changed my start command to nohup java -Dorg.jenkinsci.plugins.gitclient.Git.useCLI=true -jar ~/Downloads/jenkins.war --httpPort=8081 --ajp13Port=8010 > /tmp/jenkins.log 2>&1 &
, and now I get a different crash:
Started by user anonymous
Building in workspace /Users/ethen/.jenkins/workspace/Build NikNik
> git rev-parse --is-inside-work-tree
Fetching changes from the remote Git repository
> git config remote.origin.url git@bitbucket.org:ethenwilson/whentoact.git
Fetching upstream changes from git@bitbucket.org:ethenwilson/whentoact.git
> git --version
using GIT_SSH to set credentials NikNik BitBucket SSH Key
> git fetch --tags --progress git@bitbucket.org:ethenwilson/whentoact.git +refs/heads/*:refs/remotes/origin/*
FATAL: Failed to fetch from git@bitbucket.org:ethenwilson/whentoact.git
hudson.plugins.git.GitException: Failed to fetch from git@bitbucket.org:ethenwilson/whentoact.git
at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:622)
at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:854)
at hudson.plugins.git.GitSCM.checkout(GitSCM.java:879)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1252)
at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:624)
at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:530)
at hudson.model.Run.execute(Run.java:1732)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
at hudson.model.ResourceController.execute(ResourceController.java:88)
at hudson.model.Executor.run(Executor.java:234)
Caused by: hudson.plugins.git.GitException: Command "git fetch --tags --progress git@bitbucket.org:ethenwilson/whentoact.git +refs/heads/*:refs/remotes/origin/*" returned status code 128:
stdout:
stderr: Permission denied (publickey).
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.
at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1406)
at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:1194)
at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.access$200(CliGitAPIImpl.java:87)
at org.jenkinsci.plugins.gitclient.CliGitAPIImpl$1.execute(CliGitAPIImpl.java:265)
at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:620)
... 10 more
回答1:
I had this problem as well and was only able to solve it by deleting the workspace of the problematic repository on our master Jenkins server.
I think the problem was that there was a connection-error (like @gbjbaanb said) in a few of the builds (our Bitbucket crashed). This left the workspace on master in a corrupt state, and because Jenkins tries to use cached workspaces where it can, this caused every following build to fail as well.
回答2:
1) Go to job configuration
2) Go to the "Source Code Management" section
3) Additional behaviors > add
4) Select "Wipe out repository and force clone"
This will delete and re-clone only the workspace which is for your job. If you'd like to confirm before deleting, then I suggest echoing out the $WORKSPACE variable via a batch/bash command build step.
Also, this makes the build much slower, so I suggest removing it after one build.
回答3:
Seems like a network error:
Receiving objects: 78% (2092/2682), 4.07 MiB | 1.59 MiB/s
Corrupted MAC on input.
Disconnecting: Packet corrupt
fatal: The remote end hung up unexpectedly
fatal: early EOF
fatal: index-pack failed
suggests the network broke at 78% of the way through.
Seems to be a common problem.
回答4:
For me, this was hitting the 10 minute default timeout for the git-client plugin.
Solved by setting an advanced clone behaviour on the job and upping the timeout.
In the job configuration page under the Git plugin section, there is a drop-down list "Add". Within that dropdown list there is a selection "Advanced clone behaviours". When you add the advanced clone behaviors, you'll see a field for "Timeout (in minutes) for clone and fetch operation".
If you add additional behaviours before the operation you can up the timeout for clone and checkout - which has translated to a higher timeout value in my console
- Advanced Checkout behaviours
- Advanced Clone behaviours
Putting any value in timeout overrides the default.
Knowledge gained from JENKINS-20445.
回答5:
This issue is probably caused by a timeout check in place while fetching. You can increase it by following the advice mentioned below.
In the job configuration page under the Git plugin section, there is a drop-down list "Add". Within that dropdown list there is a selection "Advanced clone behaviours". When you add the advanced clone behaviors, you'll see a field for "Timeout (in minutes) for clone and fetch operation".
回答6:
I was able to solve the problem by creating a BitBucket account exclusively for Jenkins, giving it admin permission to the repository.
I then had the repository URL be: https://JenkinsAccountUsername:JenkinsAccountPassword@bitbucket.org/OwnerOfRepositoryUsername/ProjectName.git
.
回答7:
I solved a similar issue by switching 'ssh' to 'https' when connecting to BitBucket. Remember on bitbucket UI, when clicking 'clone', there's dropdown options for ssh/https. After using https the git pulling works.
回答8:
I faced a similar timeout issue in my windows server where my remote GIT repository was huge and very slow to clone.
I have done the following to fix the timeout issue based on the suggestions from this post.
Manually clone the repository (not necessarily
git clone --mirror git@github.com:my-user/my-repository.git
as I had already cloned it in a folder before I could stumble on the second suggestion. Anyway if you are starting newly probably you can clone withmirror
option). This will act as my reference repository.Configure the
Source Code Management
in your jenkins job as follows
Repositories: Configure this as you would normally
Branches to build: Configure this as you would normally
Repository browser: (Auto) (Default value)
Additional Behaviours: Advanced clone behaviours
Fetch Tags - Unchecked
Honor refspec on initial clone - Unchecked
Shallow clone - Checked
Shallow clone depth - 1 (We are not bothered about the whole history, only latest is enough)
Path of the reference repo to use during clone - Folder path of the repo where the entire repo is cloned (refer Step 1 above)
Timeout (in minutes) for clone and fetch operations - Left blank in my case (If you need a different timeout (default is 10 mins) you can mention it here)
来源:https://stackoverflow.com/questions/24813816/why-is-jenkins-failing-when-fetching-from-git-while-the-command-line-isnt