Підмодулі Git, які не оновлюються у побудові Jenkins

У мене є підмодуль у проекті у Дженкінсі. Я ввімкнув розширені налаштування для рекурсивного оновлення підмодулів.

Коли я запускаю збірку, я бачу, що в робочій області є файли з підмодуля. Проблема полягає в тому, що це, здається, перша редакція підмодуля. Коли я натискаю на зміни (сховище, розміщене на GitHub), Дженкінс, здається, не оновлює підмодуль, щоб отримати правильні зміни. Хто-небудь коли-небудь бачив це?

Зверніть увагу, що плагін Jenkins Git 2.0 матиме "попередню поведінку підмодуля", що має забезпечити належне оновлення підмодулів:

Як зазначив по vikramvi:

Advanced sub-modules behavior> " Path of the reference repo to use during submodule update" проти цього поля додайте підмодуль git url.

Оуен Б згадує в коментарях :

Що стосується проблеми автентифікації, тепер існує опція "Використовувати облікові дані із віддаленого батьківського сховища за замовчуванням"

Тут, у JENKINS-20941 :

Це висвітлено в документації до плагіна Git на сайті Jenkins у розділі: Рекурсивні підмодулі .

Плагін GIT підтримує сховища з підмодулями, які в свою чергу мають самі підмодулі. Однак це потрібно ввімкнути: у конфігурації завдання -> Розділ Керування вихідним кодом , Git -> Розширена кнопка (у розділі Відділення для побудови) -> Рекурсивне оновлення підмодулів .

Приклад

На екрані конфігурації вашої роботи, у розділі Керування вихідним кодом, натисніть кнопку " Додати" вниз і виберіть "Розширена поведінка підмодулів".

Потім виберіть "Рекурсивно оновлювати підмодулі":

Чи знаєте ви, що ваше сховище Git завжди посилається на певну редакцію підмодуля? Дженкінс не збирається автоматично змінювати версію.

Якщо ви хочете застосувати нову редакцію підмодуля, вам доведеться зробити це у вашому локальному сховищі Git:

cd submoduledir
git pull
cd ..
git add submoduledir
git commit -m 'Updated to latest revision of submoduledir'
git push # Go and watch Jenkins build with the new revision of the submodule

Коли ви робите це так, Дженкінс перевірить той самий перегляд підмодуля під час побудови. Дженкінс самостійно не вирішує, яку редакцію підмодуля використовувати. У цьому полягає принципова різниця між підмодулями Git та зовнішніми SVN.

Можливо, ви захочете прочитати хорошу довідку про підмодулі, наприклад http://progit.org/book/ch6-6.html .

Нарешті натрапив на спосіб зробити це, і це просто.

Питання:

Початковий клон з обліковими даними працює нормально, але подальше submoduleклонування не вдається з неправильними обліковими даними.

1. Автоматичне розширене клонування підмодуля Source Code Management >> Additional Behaviours >> Advanced sub-modules behaviours:: призводить до помилки облікових даних.
2. git submodule update --initу Execute Shellрозділі також не вдається з помилкою облікових даних.

Рішення:

Я використовую jenkins-1.574.

1. Поставте Build Environment >> SSH Agentпрапорець.
2. Виберіть правильні облікові дані (можливо, ті самі, що вибрані в Source Code Managementрозділі

3. Оновіть підмодулі в Execute Shellрозділі

   git submodule sync
   git submodule update --init --recursive
   

Ось знімок екрану

Схоже, я знайшов рішення:

Я додав крок збірки для виконання наступних команд оболонки:

git submodule foreach git checkout master
git submodule foreach git pull

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

Я використовую сценарій конвеєризації з плагіном checkout. Якщо ви хочете, щоб підмодулі були такими ж, як у вашому сховищі, просто вимкніть параметр trackSubmodules таким чином:

checkout([$class: 'GitSCM', branches: [[name: '*/develop']], doGenerateSubmoduleConfigurations: false, extensions: [[$class: 'SubmoduleOption', disableSubmodules: false, parentCredentials: true, recursiveSubmodules: false, reference: '', trackingSubmodules: false]], submoduleCfg: [], userRemoteConfigs: [[credentialsId: '[myCredentials]', url: 'https://git.myRepo.git']]])