Jenkins slave под локальным админом - не работает git push


#1

Добрый день.
Помогите с такой проблемой.

Сначала я настроил запуск slave ноды в своей учетке. И мелькание черных окон при запуске разных задач Jenkins сильно отвлекает.

Посоветовали создать локального админа на этой машине и запускать slave ноду из под этого пользователя через планировщик.

Ок. так и сделал. Slave заработала под пользователем CI-bot включенным в группу Администраторы.

Однако теперь не работает такая команда
git push origin master
В логах написано так:

J:\QA\jenkins_slave\workspace(c3) Gitsync>git push origin master
error: src refspec master does not match any.
error: failed to push some refs to ‘https://…адрес репозитория гитлаб …git’

я через выполнить шаг win установил пользователя и пароль глобально

git config --global user.name 
git config --global user.email 

такие же как и в моей учетке ОС. Не уверен, что это на что-то влияет. но результат тот же

Затем я в gitlab в настройках репозитория установил настройку в Protected Branches сделал настройку Allowed to push = Developers+masters
В задаче пользователь git от которого Jenkins делает Push (по идее) установлен CI-bot и credentials в git тоже от него. В гитлабе этот пользователь гитлаба (CI-bot) включен в проект с правами developer

Что-то стало не так, когда slave стал запускаться под другой учеткой ОС.
Подскажите, где и как учетка windows участвует в авторизации на gitlab ?

Или может я не настроил чего-то еще?

Другая учетка ОС для slave ноды нужна еще и по совету в FAQ в проекте add
Чтобы работали тесты кнопконажималки и скрины были не черным окном.


#2

git credentional manager - это служба которая сохраняет windows Credentinlal
в профиле пользователя по которым запускался git

Вот так это выглядит


#3

В принципе я советую на Слейве сделать git credential-manager uninstall

И работать уже через jenkin set user:pass


#4

В планировщике я установил запуск J:/jenkins-slave/start.bat под своим пользователем, под которым я захожу через RDP.
Задача gitsync заработала, мелькание черных окон прекратилось, тихонько шуршит где-то.
Сборочная линия на шаге запуска тестов на VB также не мешает открыванием окон 1C.
В этой части проблема как бы решена.

Осталась проблема с черными окнами в кнопконажималке.

Рекомендации в FAQ проекта не понятны и вызывают вопросы:

  1. “Нельзя использовать для доступа к CI RDP. Вообще” что это значит?
    под своей учеткой я хожу по RDP на комп где под моей же учеткой запущен slave. Значит ли это что к CI я имею доступ через RDP? сам CI (веб интерфейс) я вижу в браузере внутри сеанса RDP. А сервер CI вообще на линуксе крутится на другой машине в сети.
    И как следствие - будет ли это причиной черных скриншотов?

  2. “На CI надо настроить автовход под какой либо учётной записью и в автозагрузку надо поместить команду запуска джоба Jenkins”
    В этой части я настроил автовход под некоей учеткой (моей) и поместил в автозагрузку стартер slave ноды.
    Этого достаточно ? или что-то еще нужно?

*Самих тестов кнопконажималки у меня пока нет. Весь функционал add для меня новый и его нужно осваивать. Я пока пытаюсь запустить сценарии написанные для VB 1,1,094 под обычный клиент, где нет UI тестов.


#5

мигрируй на ADD - там есть обычный клиент. Тем более сейчас там идут обновления связанные именно с обычными формами

P.S. Потому что идет проект внедрения :wink: как раз для УПП - поэтому там идут активные доработки именно по режим обычным форм


#6

В целом процесс миграции начался, почему и вопросы задаю ))

Обновления проекта add получать нужно через opm update, а не через сабмодуль гит, верно?


#7

ага, плюс рекомендация делай ярлык на рабочем столе на папку с ADD

P.S. Пока не будет выполнен вот это issue https://github.com/silverbulleters/add/issues/191


#8

Если я так сделаю, тогда этот менеджер удалится с компа совсем, а не только для конкретного пользователя ОС.
И я не смогу пушить в гитлаб например с помощью source tree без постоянного ввода пароля к гиту
Или эта команда отключит менеджер только для той учетки, под которой эту команду выполню ?

вот это тоже не понятно.
то, что записано в generic credentials в винде, это логин пароль пользователя гитлаба, который винда запрашивает первый раз когда я синхронизирую с удаленным репозиторием. И потом каждый пуш проходит под этим пользователем.
В Jenkins подобная связка логин/пароль гитлаба устанавливается в настройке задачи pipeline.
Получается что даже если в задаче Jenkins установлены логин пароль от CI-bot, каждый пуш он делает все равно от того пользователя который сохранен в generic credentials в винде?

И если его удалить git credential-manager uninstall, тогда будут работать настройки из задачи в Jenkins.\Верно?