Gitlab CI. Как задать разные значения переменных для разных веток?

Question

[goodweather]

Я пытался решить задачу следующим образом:

image: alpine

variables: &global_variables
    ENV_VARIABLE: ${VAR_$CI_COMMIT_BRANCH}

stages:
    - test

test_job:
    stage: test
    variables:
        <<: *global_variables
    script:
        - echo "This job ran on the $CI_COMMIT_BRANCH branch."
        - echo "$CI_COMMIT_BRANCH - $ENV_VARIABLE"

В настройка CI прописал такие переменные:

VAR_master: "Это мастер"
VAR_dev: "Это дев"

И когда я делаю push в мастер у меня всё работает, я получаю сообщение "Это мастер". Однако когда я делаю тоже самое в деве, то не получаю ожидаемого сообщения "Это дев".

Почему так может происходить?
Или может моя задача решается другим способом? Как это можно сделать?

Comments

[mureevms]

Окрежение != ветка. Мне кажется, вам надо сделать разные окружения. Это весь .gitlab-ci?

[goodweather]

Нет, это тестовый ci для поиска решения.

У меня есть две версии приложения. master и дев. Их job'ы отличаются только веткой и, например, адресом сервера и директорией на этом сервере. Сейчас для каждой ветки у меня отдельные job's, одинаковые по сути. От этого дублирования я пытаюсь избавиться.

Поясните, пожалуйста, что вы подразумеваете под окружением в данном контексте? В каком направлении копать?

[Станислав Макаров]

Или может моя задача решается другим способом?

В этом как раз и проблема - мы видим не изначальную задачу, а вашу попытку решить её.

Например, не очень хорошая идея привязывать окружения для развёртывания к конкретному бранчу. Так оправдано делать разве что для кода инфраструктуры (terraform и к нему приравненные), и то не всегда удобно.

Вероятно, mureevms говорит о том же. Вы должны иметь возможность разворачивать различные ветки в различные окружения, с некоторыми ограничениями вроде "в прод только из мастера". Например, почему бы вам не развернуть мастер в тестовое окружение?

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

Приведу пример. Операция слияния веток - вещь небезопасная по своей природе. Даже если по мнению Гита конфликтов у вас нет, чисто на уровне текста исходников, это не значит что результат слияния - работающий код. Он может не скомпилироваться или тесты могут не пройти (а если тестов нет - вы об этом не сразу узнаете). После слияния полученное состояние репозитория необходимо прокатать в CI и потестить в тестовом окружении.

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

[Станислав Макаров]

Сейчас для каждой ветки у меня отдельные job's, одинаковые по сути.

А какие по факту отличия всё-таки есть?

[goodweather]

Станислав Макаров,

image: alpine

# Глобальные переменные для дева
variables: &global_variables_dev
    ENV_PRIVATE_KEY: $STAGING_PRIVATE_KEY
    PROJECT_HOST: "root@87.250.250.242"
    PROJECT_PATH: "/var/www/siteA"
    SSH_PORT: 22

# Глобальные переменные для продакшена
variables: &global_variables_prod
    ENV_PRIVATE_KEY: $PRODUCTION_PRIVATE_KEY
    PROJECT_HOST: "root@173.194.222.94"
    PROJECT_PATH: "/var/www/site1"
    SSH_PORT: 22

.prepare_ssh_connection: &prepare_ssh_connection
    - 'which ssh-agent || ( apk update && apk add openssh-client )'
    - eval $(ssh-agent -s)
    - echo "$ENV_PRIVATE_KEY" | ssh-add -
    - mkdir -p ~/.ssh
    - echo "$SSH_KNOWN_HOSTS" > ~/.ssh/known_hosts

pull_dev:
    stage: deploy_after
    variables:
        <<: *global_variables
        <<: *global_variables_dev
    only:
        refs:
            - dev
    before_script:
        - *prepare_ssh_connection
    script:
        - ssh -p $SSH_PORT $PROJECT_HOST "cd $PROJECT_PATH/ && git checkout $CI_COMMIT_BRANCH && git pull --force origin $CI_COMMIT_BRANCH"

pull_prod:
    stage: deploy_after
    variables:
        <<: *global_variables
        <<: *global_variables_prod
    only:
        refs:
            - master
    before_script:
        - *prepare_ssh_connection
    script:
        - ssh -p $SSH_PORT $PROJECT_HOST "cd $PROJECT_PATH/ && git checkout $CI_COMMIT_BRANCH && git pull --force origin $CI_COMMIT_BRANCH"

Это более наглядный пример. pull_prod и pull_dev отличаются веткой и значениями переменных. Моя цель заменить это одной job'ой. С переменными меняющими своё значение в зависимости от ветки.

[mureevms]

Станислав Макаров, именно это я и имел ввиду )
goodweather, с этого и надо было начинать. Так сделать невозможно средствами Гитлаба. Существует вариант - разместить эту переменную в файле, которая будет парсится/вставляться как системная переменная при деплое. Но это не тру подход. Лучше иметь две джобы и две переменных для них, поскольку рано или поздно кто-то забудет изменить/не изменить ее в коде и в прод приедет дев.

Answer 1

[Bladegreat]

Для этого можно использовать rules.

build-container:
  stage: build
  rules:
    - if: '$CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH'
      variables:
        image_tag: "$CI_REGISTRY_IMAGE"
      changes:
        - Dockerfile
    - if: '$CI_COMMIT_BRANCH != $CI_DEFAULT_BRANCH'
      variables:
        image_tag: "$CI_REGISTRY_IMAGE:$CI_COMMIT_REF_SLUG"
      changes:
        - Dockerfile
  services:
    - docker:18-dind
  before_script:
    - docker login -u "$CI_REGISTRY_USER" -p "$CI_REGISTRY_PASSWORD" $CI_REGISTRY
  script:
    - docker build --pull -t ${image_tag} .
    - docker push ${image_tag}