Fastlane match не может подключиться через SSH
Существующие решения
Я тщательно искал SO и Github, прежде чем задать свой вопрос. Ни в одной из существующих тем нет рабочих решений для нашей установки.
Конфигурация
У нас есть Jenkins + Fastlane, настроенный на удаленной машине с macOS. Предполагается, что Fastlane match получает учетные данные для подписи (сертификат + профиль обеспечения) из выделенного репозитория через SSH.
Проблема
Соединение SSH не работает (зависает). Вывод консоли Дженкинса:
INFO [2019-04-09 14:09:29.05]: Cloning remote git repo...
INFO [2019-04-09 14:09:29.05]: If cloning the repo takes too long, you can use the `clone_branch_directly` option in match.
INFO [2019-04-09 14:09:29.05]: [36m$ git clone ssh://[email protected]:xxxx/cert/ios-certificates-profiles.git /var/folders/_redacted_[0m
INFO [2019-04-09 14:09:29.07]: ▸ [35mCloning into '/var/folders/_redacted_'...[0m
INFO [2019-04-09 14:09:29.19]: ▸ [35mThe authenticity of host '[xxx.xx.x.xxx:xxxx]:xxxx ([xxx.xx.x.xxx:xxxx]:xxxx)' can't be established.[0m
INFO [2019-04-09 14:09:29.19]: ▸ [35mRSA key fingerprint is _REDACTED_.
Выполнение команды «git clone ssh://[email protected]:xxxx/…» из терминала на том же компьютере:
- успешно клонирует репозиторий
- добавляет хост в файл known_hosts
Тем не менее Дженкинс продолжает висеть на команде матча на скоростной полосе. Есть идеи, почему Дженкинс не может подключиться к репозиторию через SSH? Что мне не хватает?
Редактировать
Добавление опции clone_branch_directly к команде match не дает результата, команда все равно зависает.
Ответы 3
Сначала попробуйте ту же операцию с Jenkins, запущенную в среде, где для переменной GIT_SSH_COMMAND установлено значение «ssh -vvv»: это даст вам полные трассировки, когда Git попытается клонировать с URL-адресом SSH.
ОП ммви подтверждает в комментариях:
Adding verbose logging to SSH revealed Jenkins was ran as
sudo.
Running Jenkins not as sudo and pointing to the correct SSH keys resolved the issue.
Другие возможности:
проблема с полосой обгона 5473 упоминает проблему known_hosts, но если отпечаток удаленного сервера уже добавлен (при условии, что ваш Jenkins работает с тот же аккаунт в качестве вашего собственного сеанса оболочки), проверьте, защищен ли ваш закрытый ключ парольной фразой:
FWIW, when I
ssh-add -Dand then runfastlane certs(which runs match), I get the exact same behavior. It hangs on "Cloning remote git repo..." That's expected behavior. 'ssh-add' fixes things.
То же самое в проблема с полосой обгона 7482:
Figured it out...was on a new box and hadn't added my key to ssh-agent.
ssh-add -K ~/.ssh/id_rsa
Другая возможность: проблема с полосой обгона 11732:
I'm running into this on CircleCi 2.0 as well
Setting this in my environment configuration on Circle 2.0 helps
environment:
TERM: xterm-256color
Поэтому проверьте значение переменной среды $TERM.
Добавление подробного ведения журнала в SSH показало, что Jenkins запускался как sudo. Запуск Jenkins не как sudo и указание на правильные ключи SSH решили проблему. Спасибо!
@mmvie Отлично! я включил ваш комментарий в ответ для большей наглядности.
У меня зависла задача на Circle CI на шаге матча на скоростной трассе. Причина в том, что я выполнил шаг «оформить заказ» в Linux и заставил его перебросить рабочее пространство на macos vm. Таким образом, команда «checkout» была новее настроена на машине macos, и ssh не знал имени хоста битбакета.
Это было решено путем добавления дополнительной команды «checkout» в задание macos env. Это займет немного времени, потому что все синхронизируется по рабочей области.
Я решил аналогичную проблему с
ssh-keyscan myserver.com >> ~/.ssh/known_hosts
добавление «bitbucket.org» к известным хостам решено, спасибо.
Следовали ли вы «Если клонирование репо занимает слишком много времени, вы можете использовать опцию
clone_branch_directlyв матче». совет, который он дает вам уже? Можете ли вы добавить полный вывод, который вы получаете от запуска команды вручную, для сравнения?