В GitLab CI есть переменная для целевой ветви запроса на слияние?

Question

В моем конвейере я хотел бы выполнить задание, только если целевая ветвь запросов на слияние - это определенная ветвь, скажем, master или release.

Возможно ли это?

Я прочитал https://docs.gitlab.com/ee/ci/variables/, и если я что-то пропустил, я не вижу ничего, что может помочь.

Answer 1

Из-за новых переменных env в 11.6 $CI_MERGE_REQUEST_SOURCE_BRANCH_NAME и $CI_MERGE_REQUEST_TARGET_BRANCH_NAME задания могут быть включены или исключены на основе исходной или целевой ветви.

Использование только кроме (сложных) выражений, мы можем построить правило для фильтрации запросов на слияние.Для пары примеров:

Запрос на слияние, где целевая ветвь master:

only:
    refs:
        - merge_requests
    variables:
        - $CI_MERGE_REQUEST_TARGET_BRANCH_NAME == "master"

Запрос на слияние, за исключением случаев, когда исходная ветвь master или release:

only:
    - merge_requests
except:
    variables:
        - $CI_MERGE_REQUEST_SOURCE_BRANCH_NAME == "master"
        - $CI_MERGE_REQUEST_SOURCE_BRANCH_NAME == "release"

Если вы хотите использовать несколько ссылок (скажем, merge_requests и теги) и несколько переменных, ссылки будут OR'd, переменные будут OR'd , и результатом будет AND'd :

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

Если вы используете несколько ключей только или только, они действуют как AND.Логика такова:

(any of refs) AND (any of variables) AND (any of changes) AND (if kubernetes is active)

Выражения переменных также довольно примитивны, поддерживают только равенство и (основное) регулярное выражение.Поскольку переменные будут иметь значение OR, вы не можете указать как исходную, так и целевую ветви с gitlab 11.6, только одну или другую.

Answer 2

Начиная с GitLab 11.6, CI_MERGE_REQUEST_TARGET_BRANCH_NAME.

Answer 3

Если это то, что вам действительно нужно, может быть очень запутанный (непроверенный) способ добиться этого, используя API запроса слияния и переменные CI .

С шагом рабочего процесса / сборки что-то вроде:

1. Создание запроса на слияние от feature/test до master
2. Запуск сборки
3. ИспользованиеAPI (в скрипте), захватывает все открытые запросы на слияние из текущего проекта, используя переменную CI_PROJECT_ID, и фильтрует по source_branch и target_branch.
4. Если есть запрос на слияние, открытый с source_branch и target_branch, будучи feature/test и master соответственно, продолжите сборку, в противном случае просто пропустите оставшуюся часть сборки.

Для использования API я не верю, что вы можетеиспользуйте для аутентификации переменную CI_JOB_TOKEN, поэтому вам, вероятно, потребуется создать собственный личный токен доступа и сохранить его как переменную CI для использования в задании на сборку.

Надеюсь, это поможет!

Answer 4

Обновление: 2019-03-21

GitLab содержит переменные для информации о запросе на слияние, начиная с версии 11.6 (https://docs.gitlab.com/ce/ci/variables/ см. Переменные, начинающиеся с CI_MERGE_REQUEST_).Но эти переменные доступны только в merge request pipelines. (https://docs.gitlab.com/ce/ci/merge_request_pipelines/index.html)

. Чтобы сконфигурировать задание CI для запроса на слияние, мы должны установить only: merge_request в наших заданиях для запроса на слияниеИ тогда мы можем использовать CI_MERGE_REQUEST_* переменные в этих заданиях.

Самая большая ошибка здесь - only: merge_request имеет совершенно другое поведение по сравнению с обычными only/except параметрами.

обычный only/except параметры: (https://docs.gitlab.com/ce/ci/yaml/README.html#onlyexcept-basic)

1. only определяет имена ветвей и тегов, для которых будет выполняться задание.
2. except определяетимена веток и тегов, для которых задание не будет запущено.

only: merge_request: (https://docs.gitlab.com/ce/ci/merge_request_pipelines/index.html#excluding-certain-jobs)

Поведение only: merge_requestsпараметр таков, что только задания с этим параметром выполняются в контексте запроса на слияние, другие задания не запускаются.

Мне было трудно реорганизовать задания, чтобы они работали, как раньше, с only: merge_request существует на любой работе. Таким образом, я все еще использую однострочную строку в своем исходном ответе, чтобы получить информацию MR в работе CI.

---

Оригинальный ответ:

Нет.

Но у GitLab есть план для этой функции в 2019 году Q2: https://gitlab.com/gitlab-org/gitlab-ce/issues/23902#final-assumptions

В настоящее времяМы можем использовать обходной путь для достижения этой цели.Метод описан в ответе Рековни, и он на самом деле работает.

Есть простая однострочная строка, получающая целевую ветвь MR из текущей ветки:

script: # in any script section of gitlab-ci.yml
  - 'CI_TARGET_BRANCH_NAME=$(curl -LsS -H "PRIVATE-TOKEN: $AWESOME_GITLAB_API_TOKEN" "https://my.gitlab-instance.com/api/v4/projects/$CI_PROJECT_ID/merge_requests?source_branch=$CI_COMMIT_REF_NAME" | jq --raw-output ".[0].target_branch")'

Объяснение:

CI_TARGET_BRANCH_NAME - это новая переменная, в которой хранится разрешенное имя целевой ветви.Определение переменной необязательно для различного использования.

AWESOME_GITLAB_API_TOKEN - это переменная, сконфигурированная в конфигурации переменных CI / CD хранилища.Это личный токен доступа GitLab (созданный в настройках пользователя) с областью действия api.

Параметры curl: -L позволяет curl знать о перенаправлениях HTTP.-sS делает скручивание беззвучным (-s), но показывает (-S) ошибки.-H указывает информацию о правах доступа к GitLab API.

Используемый API может быть найден в https://docs.gitlab.com/ce/api/merge_requests.html#list-project-merge-requests. Мы используем атрибут source_branch, чтобы выяснить, на каком конвейере MR выполняется текущий конвейер.Таким образом, если исходная ветвь имеет несколько MR для разных целевых ветвей, вы можете изменить деталь после | и выполнить собственную логику.

About jq (https://stedolan.github.io/jq/), этопростой CLI-утилита для работы с JSON (что возвращает GitLab API). Вы можете использовать node -p или любой другой метод, который вам нужен.

Answer 5

Gitlab CI является агностиком запросов на слияние (пока).Поскольку конвейер работает в исходной ветви, вы не сможете получить пункт назначения.