为什么 Jenkins 在从 git 获取时失败，而命令行却没有？

Question

提问by Eliza Wilson

All of my Jenkins builds are failing at the git fetchline.

我所有的 Jenkins 构建都失败了git fetch。

It's failing at git fetch --tags --progress [email protected]:ethenwilson/whentoact.git

它失败了 git fetch --tags --progress [email protected]: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 [email protected]:ethenwilson/whentoact.git
Fetching upstream changes from [email protected]:ethenwilson/whentoact.git
 > git --version
using GIT_SSH to set credentials NikNik BitBucket SSH Key
 > git fetch --tags --progress [email protected]:ethenwilson/whentoact.git +refs/heads/*:refs/remotes/origin/*
FATAL: Failed to fetch from [email protected]:ethenwilson/whentoact.git
hudson.plugins.git.GitException: Failed to fetch from [email protected]: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 [email protected]: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.access0(CliGitAPIImpl.java:87)
    at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.execute(CliGitAPIImpl.java:257)
    at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:620)
    ... 10 more

When I run git fetch --tags --progress [email protected]:ethenwilson/whentoact.gitfrom the command line, it works fine, which means my SSH keys must be working.

当我从命令行运行时git fetch --tags --progress [email protected]:ethenwilson/whentoact.git，它工作正常，这意味着我的 SSH 密钥必须工作正常。

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.

我正在通过 SSH 验证与 Jenkins 连接到 BitBucket。Jenkins 从它所在的文件中获取密钥（默认的），所以我知道 Jenkins 使用的密钥与我从命令行运行时使用的密钥相同。

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

我正在为 Jenkins 使用最新版本的 BitBucket 和 Git 插件。我在 Mac 上安装的 Git 是 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 &.

我的詹金斯启动命令是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:

编辑：我错了，当我这样做时，我不小心选择了让 SSH 密钥位于错误位置的选项。现在，使用@borrrden 的建议，它仍然给出相同的错误。**编辑：正如@borrrden 建议的那样，我将启动命令更改为nohup java -Dorg.jenkinsci.plugins.gitclient.Git.useCLI=true -jar ~/Downloads/jenkins.war --httpPort=8081 --ajp13Port=8010 > /tmp/jenkins.log 2>&1 &，现在我遇到了不同的崩溃：

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 [email protected]:ethenwilson/whentoact.git
Fetching upstream changes from [email protected]:ethenwilson/whentoact.git
 > git --version
using GIT_SSH to set credentials NikNik BitBucket SSH Key
 > git fetch --tags --progress [email protected]:ethenwilson/whentoact.git +refs/heads/*:refs/remotes/origin/*
FATAL: Failed to fetch from [email protected]:ethenwilson/whentoact.git
hudson.plugins.git.GitException: Failed to fetch from [email protected]: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 [email protected]: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.access0(CliGitAPIImpl.java:87)
    at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.execute(CliGitAPIImpl.java:265)
    at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:620)
    ... 10 more

Answer 1

回答by leondepeon

I had this problem as well and was only able to solve it by deleting the workspaceof the problematic repository on our master Jenkins server.

我也遇到了这个问题，只能通过删除我们主 Jenkins 服务器上有问题的存储库的工作区来解决它。

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.

我认为问题在于一些构建中存在连接错误（如@gbjbaanb 所说）（我们的 Bitbucket 崩溃了）。这使 master 上的工作区处于损坏状态，并且因为 Jenkins 尝试尽可能使用缓存的工作区，这也导致每个后续构建失败。

Answer 2

回答by Janac Meena

1) Go to job configuration

1) 进入作业配置

2) Go to the "Source Code Management" section

2）转到“源代码管理”部分

3) Additional behaviors > add

3) 附加行为 > 添加

4) Select "Wipe out repository and force clone"

4）选择“清除存储库并强制克隆”

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.

这将仅删除并重新克隆用于您的工作的工作区。如果您想在删除之前确认，那么我建议通过批处理/bash 命令构建步骤回显 $WORKSPACE 变量。

Also, this makes the build much slower, so I suggest removing it after one build.

此外，这会使构建速度变慢，因此我建议在构建一次后将其删除。

Answer 3

回答by Dan Caseley

For me, this was hitting the 10 minute default timeout for the git-client plugin.

对我来说，这达到了 git-client 插件的 10 分钟默认超时。

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.

在Git插件部分下的作业配置页面，有一个下拉列表“添加”。在该下拉列表中，有一个选项“高级克隆行为”。添加高级克隆行为时，您将看到“克隆和提取操作的超时（以分钟为单位）”字段。
如果您在操作之前添加其他行为，您可以增加克隆和结帐的超时时间 - 这已在我的控制台中转换为更高的超时值
高级结账行为
高级克隆行为
将任何值放入超时都会覆盖默认值。

Knowledge gained from JENKINS-20445.

从JENKINS-20445获得的知识。

Answer 4

回答by gbjbaanb

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

接收对象：78% (2092/2682), 4.07 MiB | 1.59 兆字节/秒
输入 MAC 损坏。
断开连接：数据包损坏
致命：远端意外挂断
致命：早期EOF
致命：索引包失败

suggests the network broke at 78% of the way through.

表明网络突破了 78%。

Seems to be a common problem.

似乎是一个普遍的问题。

Answer 5

回答by Sadiq Ali

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

在Git插件部分下的作业配置页面，有一个下拉列表“添加”。在该下拉列表中，有一个选项“高级克隆行为”。添加高级克隆行为时，您将看到“克隆和提取操作的超时（以分钟为单位）”字段。

Answer 6

回答by Rajaraman

I faced a similar timeout issue in my windows server where my remote GIT repository was huge and very slow to clone.

我在我的 Windows 服务器中遇到了类似的超时问题，我的远程 GIT 存储库很大而且克隆速度很慢。

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 [email protected]:my-user/my-repository.gitas 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 mirroroption). This will act as my reference repository.
Configure the Source Code Managementin your jenkins job as follows

手动克隆存储库（不一定，git clone --mirror [email protected]:my-user/my-repository.git因为在我偶然发现第二个建议之前我已经将它克隆到了一个文件夹中。无论如何，如果你是新开始，你可能可以选择克隆mirror）。这将作为我的参考存储库。
Source Code Management在您的 jenkins 作业中配置如下

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 1above)
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)

存储库：像往常一样配置它
要构建的分支：像往常一样配置它
存储库浏览器：（自动）（默认值）
附加行为：高级克隆行为
获取标签 -未选中
尊重初始克隆的 refspec -未选中
浅克隆 - 已检查
浅克隆深度 - 1（我们不关心整个历史，只有最新的就足够了）
克隆期间要使用的参考存储库的路径- 复制整个存储库的存储库的文件夹路径（请参阅上面的第 1 步）
克隆和获取操作的超时（以分钟为单位） -在我的情况下留空（如果您需要不同的超时（默认为 10 分钟），您可以在此处提及）

Answer 7

回答by Emily

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.

我通过在连接到 BitBucket 时将“ssh”切换到“https”解决了类似的问题。请记住在 bitbucket UI 上，单击“克隆”时，有 ssh/https 的下拉选项。使用 https 后，git pull 工作。

Answer 8

回答by Eliza Wilson

I was able to solve the problem by creating a BitBucket account exclusively for Jenkins, giving it admin permission to the repository.

我能够通过专门为 Jenkins 创建一个 BitBucket 帐户来解决这个问题，并授予它对存储库的管理员权限。

I then had the repository URL be: https://JenkinsAccountUsername:[email protected]/OwnerOfRepositoryUsername/ProjectName.git.

然后我将存储库 URL 设为：https://JenkinsAccountUsername:[email protected]/OwnerOfRepositoryUsername/ProjectName.git。

为什么 Jenkins 在从 git 获取时失败，而命令行却没有？

提问by Eliza Wilson

回答by leondepeon

回答by Janac Meena

回答by Dan Caseley

回答by gbjbaanb

回答by Sadiq Ali

回答by Rajaraman

回答by Emily

回答by Eliza Wilson

相关推荐

最近更新

标签

为什么 Jenkins 在从 git 获取时失败，而命令行却没有？

提问by Eliza Wilson

回答by leondepeon

回答by Janac Meena

回答by Dan Caseley

回答by gbjbaanb

回答by Sadiq Ali

回答by Rajaraman

回答by Emily

回答by Eliza Wilson

相关推荐

git 如何使用 SourceTree 将本地存储库推送到 Bitbucket 而无需先在 bitbucket 上创建存储库？

git 如何从现有的远程分支创建本地分支？

git 如何在 Eclipse 中添加 GitLab 存储库？

来自不同用户的 Git pull 命令

相关推荐

最近更新

标签