Почему 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 минут), вы можете упомянуть его здесь)