Недавно я начал видеть вышеуказанную ошибку с постоянно увеличивающейся частотой на нашем сервере сборки. В нашей конфигурации TeamCity за этот период ничего не изменилось, поэтому я предполагаю, что причиной ошибки могут быть изменения в GitHub.
Я попытался изменить интервал опроса VCS с 60 до 600 секунд на случай, если GitHub выполнял какое-то регулирование соединения, но это не повлияло.
Можно ли сделать TeamCity менее чувствительным к тайм-аутам соединения?
Для доказательства попробуйте сделать это на своем сервере, где установлен TC.
(командная строка, разумеется)
C:\git\bin\git.exe clone https://github.com/libgit2/libgit2.git
и это не должно работать большую часть времени.
Итак, в AZURE есть сетевая ошибка, и они знают об этом и пытаются решить проблему.
Эта информация была предоставлена через GitHub после того, как они работали с Azure, чтобы выяснить, что происходит.
Вы должны использовать SSH KEYS в качестве текущего обходного пути.
Мы сделали его менее чувствительным: теперь git-плагин будет повторять операцию в случае ConnectException. Чтобы получить такое поведение, вам необходимо установить последнюю сборку git-плагина из teamcity.jetbrains.com. Для этого поместите zip из артефактов сборки в <TEAMCITY_DATA_DIR>/plugins и перезапустите сервер.
Вы разместили мало информации для вопроса. Было бы лучше, если бы вы могли отправить команду по электронной почте [email protected] с более подробной информацией и журналами отладки с сервера TeamCity.
Некоторые вещи, которые легко проверить: * вы можете открыть github.com с сервера в браузере * вы можете клонировать github.com на сервер из консоли
У нас внезапно появилась эта ошибка сегодня (23 февраля 2018 г.).
Оказывается, GitHub.com устарел от некоторых алгоритмов безопасности в своей реализации ssh.
Решения:
Вот объявление от JetBrains: https://teamcity-support.jetbrains.com/hc/en-us/community/posts/360000115644-Builds-using-GitHub-com-fail-with-VCS-errors-since-February-22-FIX-AVAILABLE
Переход на ssh помог нам избежать таймаутов.
Как говорит @Pure.Krome, вы можете использовать SSH KEYS, чтобы получить доступ к URL-адресу Azure TFS GIT, или вы можете изменить настройки в «Альтернативные учетные данные», установив флажок «Включить альтернативные учетные данные», чтобы вы могли получить доступ к репозиторию, просто используя имя пользователя и пароль.
Сначала в Azure DevOps перейдите в свой проект:
Затем выберите Security в меню RHS:
Наконец, выберите «Альтернативные учетные данные» в меню LHS и нажмите «Включить альтернативные учетные данные аутентификации», где вы затем введете свое имя пользователя и пароль:
Помните, что это менее безопасно, чем использование SSH KEYS.
У меня возникла эта проблема даже при использовании ssh. Я понял, что существует брандмауэр, который воспринимает весь ssh-трафик как атаку грубой силы ssh. Затем брандмауэр заблокирует запрос.
Для решения проблемы было добавлено правило брандмауэра.
