|
|
|
Существуют ситуации, когда изменения в одном репозитории, тянут изменяя в другом репозитории. Бывает необходимость в билде одновременно нескольких репозиториев с новыми изменениями, что при обычном checout эмулировать **было невозможно**. Сейчас появилась возможность делать MR, который зависит от других сабмодулей.
|
|
|
|
|
|
|
|
По сути, нужно взять **Work** необходимой ветки (существует возможность работы с эпиковой веткой Work - см. ниже), и в нём каждый сабмодуль нужно слить все **Source и Target** ветки. То есть получить **Work**, в котором каждый изменённый сабмодуль имеет **Source** ветки.
|
|
|
|
|
|
|
|
[[_TOC_]]
|
|
|
|
|
|
|
|
# **Синхронный 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
|
|
|
|
1. По этим параметрам Jenkins делает checkout репозитория Work `Target branch`
|
|
|
|
1. После чего проверяет есть ли в сабмодулях обе ветки (`Target branch` и `Source branch`)
|
|
|
|
1. Когда находится сабмодуль с этими ветками, то для него берется состояние ветки, которая мёржится `Source branch`
|
|
|
|
1. В результате получается состояние Work, как при создании руками необходимого состояния **Work** при билде
|
|
|
|
1. Далее Jenkins будет билдить по очереди проекты, которые советуют сабмодулю в котором сделан MR:
|
|
|
|
1. При успешном билде, 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` |
|
|
|
\ No newline at end of file |
