Куда пушить изменения для сборки проекта в Jenkins?

Question

[OwDafuq]

Суть: есть build-ветка, которая собирается в Jenkins.
Проект имеет подмодуль, который может обновиться и в build-ветке может/будет находиться информация, что мы находимся на коммите № 1 (когда уже написали 2 фичи и сделали 2 коммита).
При инициализации модулей в Jenkins мы перепрыгнем на коммит № 3 в модуле и появятся изменения (что модуль находится на коммите № 3, а не на № 1).

Куда эти изменения коммитить и пушить? В саму build-ветку? Если да, то если Jenkins pipeline настроен на проверку SCM, то Jenkins при повторной проверке изменений в репозитории увидит свой же коммит и начнет пересобирать проект еще раз, что не хотелось бы. Или заводить каждый раз отдельную ветку с, например, текущей датой и временем или завести еще одну ветку, например post-build и пушить изменения в модулях в неё, чтобы потом можно было эти изменения накатить на master?

Вот такое я вижу в Jenkins сейчас:

> git submodule update --init --recursive --remote modules/test2 # timeout=10
[Pipeline] }
[Pipeline] // script
[Pipeline] }
[Pipeline] // stage
[Pipeline] stage
[Pipeline] { (Git commit changes)
[Pipeline] script
[Pipeline] {
[Pipeline] withCredentials
Masking supported pattern matches of $GIT_PASSWORD
[Pipeline] {
[Pipeline] sh
+ git status
HEAD detached at 16ea377
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
    modified:   modules/test2 (new commits)

Answer 1

[Vitaly Karasik]

Да, в саму ветку.
Как предотвратить новый триггер? - https://community.jenkins.io/t/is-it-possible-not-....

https://plugins.jenkins.io/scmskip/

stages {
            stage('Checkout') {
                steps {
                    scmSkip(deleteBuild: true, skipPattern:'.*\\[ci skip\\].*')
                }
            }

Comments

[OwDafuq]

На сколько будет хорошей практикой такой расклад:
1) 1 задача смотрит в master ветку (она же dev) и просто обновляет сабмодули и делает коммиты этих изменений
2) 2 задача смотрит в build ветку (она же prod), собирает и выкатывает в прод приложение
3) Вся разработка ведется в master'e и игнорируется для сборки

Хотелось бы автоматизировать обновление сабмодулей, чтобы руками не обновлять их

[Vitaly Karasik]

OwDafuq,
Я всегда советую забыть для начала о Jenkins, CICD и прочем - и написать на листочке или в Notepad список действий для билда и деплоя вручную. А потом автоматизировать.
CICD не должен приносить новых сложностей, он просто автоматизирует этот процесс.

В вашем случае я бы начал с вопроса "когда мы хотим стартовать билд/деплой?" - при изменении основного кода или при изменениии сабмодуля?

[OwDafuq]

Vitaly Karasik, билд и деплой должны стартовать после изменения основного кода. Но есть пару критичных сабмодулей, за которыми стоит следить пристально и они должны точно попадать в деплой. Например: инициализация настроек приложения, была ошибка в сабмодуле - её исправили и надо сделать билд + деплой после этого, но основной код никак не поменяется.

[Vitaly Karasik]

OwDafuq,
OK - то есть запускаем pipeline по двум триггерам - и изменение в основном проекте, и в сабмодуле.

[OwDafuq]

Vitaly Karasik, Ок, спасибо, попробуем