Не уверен, что причина в этом, тем не менее, в задаче сборки надо вызывать gitsync через call gitsync, а не просто gitsync
GitSync поломался
Под “таким же путем к репозиторию” в настройках сборки Вы имеете ввиду раздел “Source Code Management” в задаче типа “Freestyle project”? Также у Вас стоит настройка “Additional Behaviours” “Clean before checkout”?
В таком случае возникшую у Вас ошибку можно воспроизвести даже без применения Gitsync. Здесь проблема в том, что “Clean before checkout” ничего не вычищает. Он работает исключительно командами git.
Можно взять абсолютно любой репозиторий и даже не настраивая никаких шагов, а только ограничившись двумя вышеназванными настройками, получить тот же результат :
При этом с точки зрения Jenkins всё будет в порядке ))
Достаточно выполнить вручную те же команды, которые выполняет Jenkins, чтобы также получить состояние detached HEAD. Но вот последующая явная команда checkout master должна исправлять ситуацию :
Почему в Вашем случае команда checkout master не исправляет ситуацию? Из данных Вами команд наверняка это непонятно, но есть предположение, что что-то напутано с каталогами.
У вас в качестве каталога выгрузки хранилища в команде gitsync указан абсолютный путь, а не относительный. Это значит, что вы отталкиваетесь не от текущей рабочей директории задачи Jenkins. В то же время чекаут репозитория средствами Jenkins выполняется в рабочий каталог задачи. Здесь возникает “непонятность”.
Является ли каталог J:/QA/repo одновременно и каталогом задачи Jenkins?
Сделайте перед выполнением команды gitsync вывод текущего каталога в консоль через pwd.
Это то что касается ошибки. Но давайте еще посмотрим в целом на схему работы задачи сборки и ее настройки. Они кажутся излишними при применении такой команды gitsync.
Выполнение команды gitsync с такими параметрами как у вас, то есть не gitsycn export , а gitsync ПутьКХранилищу URLРепозитория КаталогВыгрузки приводит к тому, что сам gitsync выполняет команду git pull. В этом случае предварительное получение изменений из удаленного репозитория средствами Jenkins является лишним.
Вероятно имело бы смысл выполнять получение изменений из удаленного репозитория средствами Jenkins с целью задействовать механизм очистки “Clean before checkout”. Но как Вы видели никакого полноценного очищения не происходит. Наоборот, может возникнуть нежелательная ситуация с переключением на коммит по хэшу, а не по имени ветки.
Лучше решать задачу очистки каталога также самостоятельно через вызов консольных команд, а получение изменений из репозитория средствами Jenkins отключить.
Да, именно так можно поступить. Но судя по всему в Вашем случае в этом направлении можно не копать. Проблема должна решаться более простым способом. Два репозитория лучше оставить для случая, если потом захотите разделить ответственность автоматики и человека за целостность репозиториев, чтобы человек случайно не сломал процесс автоматической выгрузки хранилища в репозиторий испортив то, что обычно безошибочно делает автоматика. Это уже отдельная тема.
2 Симпатий
Огромное спасибо, Владимир.
Я изменил путь в команде на относительный, чтобы все работало в каталоге сборки.
Видимо это работало до тех пор, пока кто-то (скорее всего я) не полазил в каталоге репозитория по абсолютному пути. Вот и сломалось.
Сейчас ошибка ушла.
С настройками получения репозитория средствами задачи сборки, которые лишние не понял.
В самой задаче я настраиваю параметры авторизации к репозиторию в гитлабе, поэтому гитсинк может делать git pull. Верно же?
Получается, что можно до запуска gitsync в разделе “выполнить команду системы” написать команду подключения удаленного репозитория и логин/пароль. А настройки подключения к репо в гитлабе убрать из задачи. Так?
В задаче Вы настраиваете параметры авторизации. Но эти параметры авторизации (Credentials) имеют отношение только к командам выполняемым git-плагином Jenkins.
К авторизации со стороны gitsync эти Credentials скорее всего отношения не имеют, сомневаюсь, что они где-то кэшируются. Наиболее вероятно, что Gitsync может успешно вызвать команду git pull по другой причине - вы ранее сохранили имя пользователя и пароль в системе Windows, задача Jenkins запускается от имени того же пользователя, под которым они были сохранены, и теперь эти параметры авторизации используются повторно. Скорее всего в Вашем случае за это отвечает компонента git называемая Git Credential Manager , устанавливаемая вместе с git :
Сами же сохраненные параметры авторизации можно увидеть через панель управления :
Смотрите, когда Вы задаете в декларативной сборочной в шаге Execute Windows batch command
набор консольных команд Jenkins действует крайне просто. Jenkins сохраняет временный bat-файл c этими командами и запускает его на выполнение. В выводе консоли появляется что-то вроде такого :
И никак иначе. И ничего на вход этого bat файла не передается. Конечно если вы задаете каждую консольную команду отдельным шагом с типом Execute Windows batch command то будет создано несколько таких bat-фпайлов и все они будут выполняться последовательно. Но опять же в них не будут каким-то неявным образом передаваться пароли к Вашему репозиторию.
Здесь не понимаю о какой команде подключения репозитория с именем пользователя и паролем идет речь.
Если мы говорим о git pull , то эта команда выполняется самим gitsync в методе ВыполнитьGitPull модуля МенеджерСинхронизации.os :
Других команд “подключения” не нужно выполнять.
И пароль при этом не передается. В случае обращения к репозиторию по http используется сохраненные в Windows параметры авторизации. В случае общащения к репозиторию через ssh будут использоваться приватные ключи из каталога .ssh домашней директории пользователя, от имени которого работает узел Jenkins.
Попробуйте отключить получение изменений средствами Jenkins. Если раньше gitsync успешно выполнял команду git pull , то и после этого будет ее успешно выполнять. И точно следует отключить криво работающую очистку репозитория средствами git-плагина Jenkins. Если нужно - делайте это сами отдельной командой.
Вообще лучше при первой же возможности перейти на авторизацию по ssh ключу, если используете gitlab. Тоже долгое время использовал подключение через http. Но в последнее время перешел на ssh и это оказалось удобнее. Если будут сложности - спрашивайте.
И еще одно замечание. Отказываться от работы с репозиторием средствами Jenkins следует только сейчас - пока у Вас простая сборочная линия. Когда перейдете на пайплайны там всё будет сложнее и интереснее. Хранить код пайплайнов имеет смысл в git-репозитории и задействовать средства Jenkins для работы с ним всё равно придется.
Что-то вроде этого я и подозревал )))
Спасибо за подробные разъяснения.
На SSH я буду переходить. Подозреваю, что наши админы потребуются, это не быстро ((
Но я буду спрашивать .
Еще раз спасибо.