GitLab CI: получить исходную ветку после того, как запрос на слияние был принят - PullRequest
Новая
       97

GitLab CI: получить исходную ветку после того, как запрос на слияние был принят

5 голосов
/ 23 января 2020

У меня есть главная ветвь, которая должна получать коммиты только путем слияния с ней ветки "release / xxxxx" или слияния с ней ветки "hotfix / xxxxx".

Конвейер для ветвь релиза создает образ docker и публикует его с помощью тега «бета».
Конвейер для ветки релиза создает образ docker и публикует его с помощью тега «исправление».

конвейер для мастера просто переназначает либо «бета» на «стабильный» (когда ветка выпуска была объединена с ведущим), либо «исправление» на «стабильный» (когда ветка исправления была объединена с главным). Затем он также создает новый тег git для этой версии и выпуск в gitlab. Наконец, образ docker развернут.

В настоящее время происходит следующее:

  • Создается запрос на слияние для слияния "release / xxxxx" с "master".
  • Конвейер запускается автоматически (до того, как запрос на слияние был принят и объединен).
  • Задание docker анализирует переменную CI_MERGE_REQUEST_SOURCE_BRANCH_NAME, чтобы определить, что исходная ветвь запроса на слияние была ветвью выпуска.
  • Затем задание docker повторно помечает "beta" как "последний".
  • Задание git добавляет тег версии и выпуск gitlab в проект.
  • Задание развертывания развертывает образ docker.

Когда запрос на слияние окончательно принят, происходит следующее:

  • Конвейер запускается снова.
  • Задание docker анализирует CI_MERGE_REQUEST_SOURCE_BRANCH_NAME, которое теперь пусто и поэтому не может определить исходную ветвь для этого слияния.
  • Сбой задания docker.

Я думаю, совершенно очевидно, что я не хочу запускать все эти задания (особенно задание развертывания ) до того, как запрос на слияние будет принят.

Но я не могу придумать хорошего способа запустить конвейер на главном сервере после того, как запрос на слияние будет принят, и затем все еще иметь возможность определить ветвь источника.

1 Ответ

2 голосов
/ 30 января 2020

Использование только информации, хранящейся в git:

при запуске после принятия запроса на слияние, фиксация HEAD должна быть результатом слияния, поэтому HEAD^2 должен быть главным коммитом ветви, которая была объединена.

Вы можете иметь информацию о:

  • тегах, которые указывают непосредственно на этот коммит: 

    git tag --points-at HEAD^2

  • ветви, которые указывают непосредственно на этот коммит: 

    git branch --points-at HEAD^2    # for local branches
git branch -r --points-at HEAD^2 # for remote branches

  • ветви, содержащие этот коммит: 

    git branch --contains HEAD^2    # for local branches
git branch -r --contains HEAD^2 # for remote branches

Используя переменные окружения, установленные gitlab:

после прочтения предопределенных переменных сделать c page , я был удивлен, что не нашел переменные, которые могли бы указать, что задание было запущено после того, как был принят запрос на слияние.

Вы можете просмотреть веб-зацепки gitlab: События запросов на слияние ; они должны предоставить достаточно информации, чтобы определить, какие ветви были задействованы в запросе о слиянии после того, как он был принят.

...