Jenkins Windows Slave игнорирует локальные настройки Git

Question

Я установил подчиненную Windows Jenkins для мастера Unix Jenkins. Я запускаю Windows 8.1 с msysgit 1.9.5 и Jenkins 1.616.

При проверке репозитория с именем пути/имени длиной более 255 символов я получаю сообщение об ошибке «Filename too long». Это значение solved, установив core.longpaths в true в настройках git. Однако подчиненный Windows Jenkins игнорирует пользовательские настройки и использует стандартные настройки.

То, что я пытался

• Установка core.longpaths на ведомом Windows, Дженкинс в глобальной системе, локальные настройки:

  git config --global core.longpaths true 
  git config --system core.longpaths true 
  git config --local core.longpaths true 
  

• Установка core.longpaths на Unix Дженкинс Master

Результат

Под управлением Windows Jenkins по-прежнему работает git с настройками по умолчанию. Я сделал простую задачу сборки с

"C:\Program Files (x86)\Git\bin\git.exe" config -l 

, который дает

Started by user mles 
[EnvInject] - Loading node environment variables. 
Building remotely on jw10 in workspace D:\workspace\windowstesting 
[windowstesting] $ sh -xe C:\WINDOWS\TEMP\hudson2817786906482449008.sh 
+ 'C:\Program Files (x86)\Git\bin\git.exe' config -l 
core.symlinks=false 
core.autocrlf=true 
color.diff=auto 
color.status=auto 
color.branch=auto 
color.interactive=true 
pack.packsizelimit=2g 
help.format=html 
http.sslcainfo=/bin/curl-ca-bundle.crt 
sendemail.smtpserver=/bin/msmtp.exe 
diff.astextplain.textconv=astextplain 
rebase.autosquash=true 
Finished: SUCCESS 

примечание нет core.longpaths=true. На ведомом Windows, Дженкинс core.longpaths=true установлен

C:\Users\jw>git config -l 
core.symlinks=false 
core.autocrlf=true 
core.longpaths=true 
color.diff=auto 
color.status=auto 
color.branch=auto 
color.interactive=true 
pack.packsizelimit=2g 
help.format=html 
http.sslcainfo=/bin/curl-ca-bundle.crt 
sendemail.smtpserver=/bin/msmtp.exe 
diff.astextplain.textconv=astextplain 
rebase.autosquash=true 

Что работает

Клонирование хранилища с очень длинным путем/имен файлов локально на подчиненном Windows, Дженкинс без Дженкинс.

Что не работает

Клонирование же хранилище с очень длинный путь/имена файлов на подчиненном сервере Windows, Дженкинс с Дженкинс

Started by user mles 
    [EnvInject] - Loading node environment variables. 
    Building remotely on jw10 in workspace D:\workspace\windowstesting 
    Cloning the remote Git repository 
    Cloning repository https://github.com/axelhodler/longfile.git 
    > git init D:\workspace\windowstesting # timeout=10 
    Fetching upstream changes from https://github.com/axelhodler/longfile.git 
    > git --version # timeout=10 
    > git -c core.askpass=true fetch --tags --progress https://github.com/axelhodler/longfile.git +refs/heads/*:refs/remotes/origin/* 
    > git config remote.origin.url https://github.com/axelhodler/longfile.git # timeout=10 
    > git config --add remote.origin.fetch +refs/heads/*:refs/remotes/origin/* # timeout=10 
    > git config remote.origin.url https://github.com/axelhodler/longfile.git # timeout=10 
    Fetching upstream changes from https://github.com/axelhodler/longfile.git 
    > git -c core.askpass=true fetch --tags --progress https://github.com/axelhodler/longfile.git +refs/heads/*:refs/remotes/origin/* 
    > git rev-parse "refs/remotes/origin/master^{commit}" # timeout=10 
    > git rev-parse "refs/remotes/origin/origin/master^{commit}" # timeout=10 
    Checking out Revision 31b408748324aa6f361828e45ae1d374c3f0fc25 (refs/remotes/origin/master) 
    > git config core.sparsecheckout # timeout=10 
    > git checkout -f 31b408748324aa6f361828e45ae1d374c3f0fc25 
    FATAL: Could not checkout null with start point 31b408748324aa6f361828e45ae1d374c3f0fc25 
    hudson.plugins.git.GitException: Could not checkout null with start point 31b408748324aa6f361828e45ae1d374c3f0fc25 
     ... 
    Caused by: hudson.plugins.git.GitException: Command "git checkout -f 31b408748324aa6f361828e45ae1d374c3f0fc25" returned status code 128: 
    stdout: 
    stderr: fatal: cannot create directory at 'launchpad/projects/configurationAdminManager/gofer-configurationAdminManager-notification/src/com/mwaysolutions/gofer2/configurationAdminManager/notification/dummydummy/dummydummy/dummydummy/dummydummy/dummydummy/dummydummy': Filename too long 
     .... 
    Finished: FAILURE 

Я не могу добавить еще выполните шаг в начале, чтобы установить core.longpaths, так как проверка хранилища - первое, что делает jenkins перед выполнением любых шагов сборки.

Любые идеи, почему пользовательские настройки игнорируются моим подчиненным Windows Jenkins?

Answer 1

Jenkins slave должно работать как пользователь jw. Это заставит git выбрать все настройки, которые вы ввели для этого пользователя.
Если вы работаете как служба, обновите службу для запуска как пользователь jw, а не как пользователь системы.

Надеюсь, это поможет.

Answer 2

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

• Настройка Multi-конфигурации проекта Дженкинс под названием что-то вроде JenkinsSlaveScripts под соответствующим видом «Admin»
• я использую безопасность матрицы на основе, чтобы обеспечить мои обычные пользователи Дженкинс не будет работать это
• Настройка оси работать на всех ваших рабов для Windows
• Добавить «выполнить пакетный сценарий Windows» задачу

Добавьте сценарий, чтобы быть (что-то вроде)

cd c:\dev-software\git-2.7.1\bin 
git config --global core.longpaths true 
git config --system core.longpaths true 
git config --local core.longpaths true 
echo %USERPROFILE%\.gitconfig on %COMPUTERNAME% 
type %USERPROFILE%\.gitconfig 

Когда она работает она должна обновить конфиг рабов, независимо от того, кем они работают, как