Why is Jenkins failing when fetching from git, while the command line isn't?

孤人 提交于 2019-11-30 06:52:06

问题


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.

  1. 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 with mirror option). This will act as my reference repository.

  2. 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

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!