Командная строка SVN в jenkins не работает из-за несоответствия сертификата сервера

Когда я запускаю командную строку svn из оболочки Jenkins, я получаю эту ошибку:

 D:\Jenkins\jobs\Merge Trunk to Stable\workspace\stable>svn up --trust-server-cert --non-interactive 
 Updating '.':
 svn: E175002: Unable to connect to a repository at URL 'https://xxx/stable'
 svn: E175002: OPTIONS of 'https://xxx/stable': Server certificate verification failed: certificate issued for a different hostname,  issuer is not trusted (https://xxx)

Но когда я запускаю то же самое из окна CMD командной строки, это нормально:

 D:\Jenkins\jobs\Merge Trunk to Stable\workspace\stable>svn up
 Updating '.':
 At revision 1797.

или

 D:\Jenkins\jobs\Merge Trunk to Stable\workspace\stable>svn up --trust-server-cert --non-interactive
 Updating '.':
 At revision 1797.

Любая идея, как решить эту проблему?

Ответ 1

Довольно старый вопрос, но все еще довольно живой.

Как вы знаете, проблема в том, что принятый кэш сертификатов (а также кеш пользователя/пароля) является для каждого пользователя, и поскольку Jenkins работает как другой пользователь (скорее всего, SYSTEM), он не имеет понятия о том, ваш обычный кеш пользователя.

Не все клиенты SVN позволяют вам делать "echo p" (это не работает для меня), а --trust-server-cert, по-видимому, тоже не работает.

Что сработало для меня, было открыть консольное окно как SYSTEM и сделать там интерактивный танец acceptcertificate-login-password.

Поскольку все это кэшируется, вам нужно сделать это только один раз, и с этого момента все svn up и подобные запросы будут работать.

Ответ 2

Наконец-то мне удалось решить проблему! То, что я сделал, просто помещено в Jenkins script:

echo p | svn up --username <usr> --password <pwrd>

Это решило! поскольку эхо эмулирует ручной ввод, чтобы постоянно принимать сертификат.

Коренной причиной является тот факт, что сценарии оболочки Jenkins выполняются под пользователем службы Windows - таким образом, используется другое место для кеша профиля пользователя (в C:\Windows\System32\config\systemprofile\AppData\Roaming\Subversion вместо %USERPROFILE%\AppData\Roaming\Subversion\)

Ответ 3

Возможно, сертификат выдается другому имени хоста (а не xxx, но что-то вроде xxx.yourcompany.com). Если да, то выполните чистую проверку с этим именем хоста.

Ответ 4

echo p | svn commands

Отлично работает в командной строке командной строки Windows Jenkins. Выполнение этого действия навсегда будет принимать сертификат для пользователя Jenkins в поле Build.

Ответ 5

Выполнение команд Svn через Дженкинса на рабе давало мне трудности. Я сделал следующее:

Если вы находитесь в unix, перейдите по этой ссылке: http://www.microhowto.info/howto/configure_subversion_to_trust_a_given_ssl_certificate.html

Если вы находитесь в Windows, выполните следующие действия:

cd %APPDATA%\Subversion\

Затем отредактируйте файл server в этом каталоге, удалив знак # из элемента ssl-authority-files и обновив путь к тому месту, где вы сохранили файл сертификата ssl.

Также измените следующее, если вам нравится хранить ваши учетные данные.

store-passwords = yes 
store-ssl-client-cert-pp = yes

После этого вам также нужно будет добавить сертификат на свою машину Windows, выполнив Добавить сертификат в хранилище доверенных корневых центров хранения

Ответ 6

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

Это был только вариант, потому что я просто настраивал этот сервер и его на полностью внутреннюю сеть, но он полностью устранил проблему. И у меня не было других вариантов и времени.

Я также предлагаю только это, если кто-то не понимает, что это даже вариант. Использование SSL сделает меня намного лучше, независимо от воздействия на сервер.

Ответ 7

Была такая же проблема с Дженкинсом и Окно 7. Я решил это, зайдя в сервисы и выбрав Jenkins и перейдите в Log-on и введите административные учетные данные и перезапустите службу jenkins.

Надеюсь, что это решит вашу проблему.