Почему Jenkins терпит неудачу при извлечении из git, а в командной строке нет?

Все мои сборки Дженкинса терпят неудачу на линии git fetch.

Сбой в 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.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

Когда я запускаю git fetch --tags --progress [email protected]:ethenwilson/whentoact.git из командной строки, он работает нормально, а это значит, что мои SSH-ключи должны работать.

Я подключаюсь к BitBucket с Jenkins с проверкой SSH. Дженкинс получает ключ из файла, который он нашел (по умолчанию), поэтому я знаю, что Дженкинс использует тот же ключ, что и я, когда я запускаю из командной строки.

Я использую последнюю версию плагинов BitBucket и Git для Jenkins. Мой установленный Git на моем Mac - версия 1.8.5.2 (Apple Git-48).

Моя команда запуска Дженкинса - nohup java -jar ~/jenkins.war --httpPort=8081 --ajp13Port=8010 > /tmp/jenkins.log 2>&1 &.

Что не так?

ОБНОВЛЕНИЕ: я был неправ, я случайно выбрал вариант, чтобы 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.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

У меня тоже была эта проблема, и я смог решить ее только с помощью удаления рабочего пространства проблемного репозитория на нашем главном сервере Jenkins.

Я думаю, проблема в том, что в нескольких сборках произошла ошибка соединения (например, @gbjbaanb) (наш Bitbucket разбился). Это оставило рабочее пространство на master в поврежденном состоянии, и поскольку Jenkins пытается использовать кэшированные рабочие области там, где это возможно, это также приводило к сбою каждой следующей сборки.

Ответ 2

1) Перейти к настройке работы

2) Перейдите в раздел "Управление исходным кодом"

3) Дополнительные варианты поведения> добавить

4) Выберите "Очистить репозиторий и принудительно клонировать"

Это приведет к удалению и повторному клонированию только той рабочей области, которая предназначена для вашей работы. Если вы хотите подтвердить перед удалением, я предлагаю вывести переменную $ WORKSPACE с помощью шага сборки команды batch/bash.

Кроме того, это делает сборку намного медленнее, поэтому я предлагаю удалить ее после одной сборки.

Ответ 3

Похоже на сетевую ошибку:

Получающие объекты: 78% (2092/2682), 4.07 MiB | 1,59 Мбайт/с

Поврежденный MAC на входе.

Отключение: поврежденный пакет

фатальный: удаленный конец неожиданно повесил трубку

фатальный: ранний EOF

fatal: сбой индекс-пакета

предполагает, что сеть сломалась на 78% пути.

Кажется, это проблема .

Ответ 4

Для меня это превышение 10-минутного таймаута по умолчанию для плагина git-client.

Решено путем установки расширенного поведения клона на задание и увеличения времени ожидания.

На странице конфигурации задания в разделе плагина Git есть раскрывающийся список "Добавить". В этом выпадающем списке есть выбор "Расширенное поведение клонов". Когда вы добавите расширенное поведение клонирования, вы увидите поле "Тайм-аут (в минутах) для операции клонирования и извлечения".

Если вы добавите дополнительные действия перед операцией, вы можете увеличить время ожидания для клонирования и извлечения, что перевело к более высокому значению времени ожидания в моей консоли

Поведение Advanced Checkout

Расширенное поведение клонов

Задание любого значения в тайм-ауте отменяет значение по умолчанию.

Знания, полученные от JENKINS-20445.

Ответ 5

Эта проблема, вероятно, вызвана проверкой тайм-аута при извлечении. Вы можете увеличить его, следуя рекомендациям, указанным ниже.

На странице настройки задания в разделе Git плагина есть раскрывающийся список "Добавить". В этом выпадающем списке есть выбор "Расширенное поведение клонов". Когда вы добавляете расширенное поведение клонов, вы увидите поле "Время ожидания (в минутах) для операции клонирования и выборки".

Ответ 6

Я смог решить проблему, создав учетную запись BitBucket исключительно для Jenkins, предоставив ей администраторское разрешение для репозитория.

Тогда у меня был URL-адрес репозитория: https://JenkinsAccountUsername:[email protected]/OwnerOfRepositoryUsername/ProjectName.git.

Ответ 7

Я решил аналогичную проблему, переключив ssh на https при подключении к BitBucket. Помните, что в пользовательском интерфейсе bitbucket при нажатии на кнопку "клон" отображаются параметры раскрывающегося списка для ssh/https. После использования https работает git pull.

Ответ 8

Я столкнулся с подобной проблемой тайм-аута на моем сервере Windows, где мой удаленный GIT-репозиторий был огромным и очень медленно клонировался.

Я сделал следующее, чтобы исправить проблему тайм-аута, основываясь на предложениях из этого поста.

Вручную git clone --mirror [email protected]:my-user/my-repository.git репозиторий (не обязательно git clone --mirror [email protected]:my-user/my-repository.git поскольку я уже клонировал его в папке, прежде чем смог наткнуться на второе предложение. В любом случае, если вы начинаете заново возможно клонировать можно с mirror опцией). Это будет служить моим справочным хранилищем.
Сконфигурируйте Управление Source Code Management в вашем задании jenkins следующим образом

Репозитории: Настройте это как обычно

Ветки для сборки: настройте это как обычно

Браузер репозитория: (Авто) (значение по умолчанию)

Дополнительные Поведения: Расширенные поведения клона

Выбрать теги - не проверено

Уважайте refspec на начальном клоне - не проверено

Мелкий клон - Проверено

Малая глубина клона - 1 (нас не волнует вся история, достаточно только последнего)

Путь ссылочного репо для использования во время клонирования - Путь к папке репо, где клонируется все репо (см. Шаг 1 выше)

Тайм-аут (в минутах) для операций клонирования и выборки - в моем случае оставьте пустым (если вам нужен другой тайм-аут (по умолчанию 10 минут), вы можете упомянуть его здесь)