Как избежать запуска двойного pipeline при использовании merge requests pipelines?
gitlab devops
Published: 2020-06-15

Пайплайны для Merge Requests существуют отдельно (имеют лейбл detached) и запускается независимо от основного pipeline. Из-за этого если сделать push в репу в ветку, из которой в гитлабе есть открытый МР, то запускаются 2 одинаковых пайплайна

  Есть варианта, чтобы это избежать:

  1. Дублировать все джобы через extends, чтобы разделить на запускаемые на МРах и на обычные
  2. Не запускать CI на некоторых ветках, пока из них нет открытого МРа

Первый вариант предполагает дублирование job, поэтому удобнее сделать второй вариант с использованием workflow:rules, который подразумевает написание правил запуска самого пайплайна, а не отдельных джоб

workflow:
  rules:
    - if: $CI_MERGE_REQUEST_ID
    - if: $CI_COMMIT_TAG
    - if: $CI_COMMIT_BRANCH == "develop"
    - if: $CI_COMMIT_BRANCH == "master"
    - if: $CI_COMMIT_BRANCH =~ /^release\/.*/

В таком случае все джобы пайплайна всегда будут запускаться на:

  1. Всех тегах
  2. Ветках с именами develop, master, release*
  3. Открытых МРах любой ветки

При этом на перечисленных ветках (CI_COMMIT_BRANCH) при наличии МРа также будет запускаться двойной pipeline, но это не является проблемой, т.к. эти ветки обычно либо не вливаются, либо вливаются редко и у них нет долгоживущих МРов (если мы говорим про gitflow). Зато на feature ветках мы не будем попусту занимать гитлаб-раннеры

Заметка

Detached пайплайны для МРов являются приоритетными и именно они показываются в статусе МРа

comments powered by Disqus