Существуют ситуации, когда изменения в одном репозитории, тянут изменяя в другом репозитории. Бывает необходимость в билде одновременно нескольких репозиториев с новыми изменениями, что при обычном checout эмулировать было невозможно. Сейчас появилась возможность делать MR, который зависит от других сабмодулей.

По сути, нужно взять Work необходимой ветки (существует возможность работы с эпиковой веткой Work - см. ниже), и в нём каждый сабмодуль нужно слить все Source и Target ветки. То есть получить Work, в котором каждый изменённый сабмодуль имеет Source ветки.

• Синхронный checkout
  • Сам алгоритм:
• Примеры:
  • Изменения только в одном cабмодуле Tools (TD-30 Тестовая задача для wiki -> Develop):
  • Изменения в двух cабмодулях Tools(TD-30 Тестовая задача для wiki -> Develop), Retail (TD-30 Тестовая задача для wiki -> Develop):
  • Работа с Эпиком Work TD-29_Epic_TestBrach. Изменения у нас в двух cабмодулях Tools(TD-30 Тестовая задача для wiki -> TD-29_Epic_TestBrach), Retail (TD-30 Тестовая задача для wiki -> TD-29_Epic_TestBrach), при состоянии Services TD-29_Epic_TestBrach:

Синхронный checkout

Скрипт Jenkins производит сначала первый checkout с Work нужной ветки (Target branch), а затем, дополнительный checkout для всех сабмодулей, если в них существуют и Source и Target ветки .

Если для успешного билда Вам необходимы изменения в разных репозиториях одновременно, то, для получения Approve от Jenkins на Ваш MR, Вам нужно что бы все сабмодули имели ветки с одинаковыми именами.

Сам алгоритм:

1. После создания Вами MR - Jenkins получает несколько нужных для нас параметров:
   • Статус Job (opened/merged)
   • Title of MR
   • Source Repo
   • Source branch
   • Target branch
2. По этим параметрам Jenkins делает checkout репозитория Work Target branch
3. После чего проверяет есть ли в сабмодулях обе ветки (Target branch и Source branch)
4. Когда находится сабмодуль с этими ветками, то для него берется состояние ветки, которая мёржится Source branch
5. Процесс повторяется для всех сабмодулей
6. В результате получается состояние Work, как при создании руками необходимого состояния Work при билде
7. Далее Jenkins будет билдить по очереди проекты, которые советуют сабмодулю в котором сделан MR:
8. При успешном билде, Jenkins берет первое слово в Title of MR и по нему определяет задачу в Jira (автоматически меняет состояние задачи в зависимости от Статуса Job)

Иногда необходимо, что бы изменения в одних сабмодулях обращались к конкретному состоянию другого сабмодуля, не связанного с Вашей задачей.

Например: Вам необходимо решать задачу с определёнными состояниями сабмодулей (не Develop и при этом не Target branch), некое состояние 3.

В таком случае создается ветка Work, которую следует назвать так же как и Target branch для решения вашей задачи.

Примеры:

Изменения только в одном cабмодуле Tools (TD-30 Тестовая задача для wiki -> Develop):

1. Создаём MR:

- Статус Job    -   opened
- Title of MR   -   TD-30 Тестовая задача для wiki
- Source Repo   -   Tools
- Source branch -   TD-30_TestBranch
- Target branch -   Develop

2. Делается checkout Work Develop
3. Проверяется существование веток TD-30_TestBranch и Develop во всех сабмодулях Work
4. Все сабмодули, которые проходят предыдущее условие, получают состояние TD-30_TestBranch, влитое в Develop
5. Получается состояние Work

6. Делается билд проектов
7. Берется первое слово Title of MR - TD-30 и задача с этим кодом меняет статус на Code Review

Изменения в двух cабмодулях Tools(TD-30 Тестовая задача для wiki -> Develop), Retail (TD-30 Тестовая задача для wiki -> Develop):

1. Создаём MR:

- Статус Job    -   opened
- Title of MR   -   TD-30 Тестовая задача для wiki
- Source Repo   -   Tools
- Source branch -   TD-30_TestBranch
- Target branch -   Develop

2. Делается checkout Work Develop
3. Проверяется существование веток TD-30_TestBranch и Develop во всех сабмодйлях Work
4. Все сабмодули, которые проходят предыдущее условие, получают состояние TD-30_TestBranch, влитое в Develop
5. Получается состояние Work

6. Делается билд проектов
7. Берется первое слово Title of MR - TD-30 и задача с этим кодом меняет статус на Code Review

Работа с Эпиком Work TD-29_Epic_TestBrach. Изменения у нас в двух cабмодулях Tools(TD-30 Тестовая задача для wiki -> TD-29_Epic_TestBrach), Retail (TD-30 Тестовая задача для wiki -> TD-29_Epic_TestBrach), при состоянии Services TD-29_Epic_TestBrach:

1. Создаём MR:

- Статус Job    -   opened
- Title of MR   -   TD-30 "Testbranch"
- Source Repo   -   Tools
- Source branch -   TD-30_TestBranch
- Target branch -   TD-29_Epic_TestBrach

2. Делается checkout Work TD-29_Epic_TestBrach
3. Проверяется существование веток TD-30_TestBranch и TD-29_Epic_TestBrach во всех сабмодйлях Work
4. Все сабмодули, которые проходят предыдущее условие, получают состояние TD-30_TestBranch, влитое в TD-29_Epic_TestBrach
5. Получается состояние Work:

6. Делается билд проектов
7. Берется первое слово Title of MR - TD-30 и задача с этим кодом меняет статус на Code Review