Этап условного запуска Gitlab-CI

#gitlab #gitlab-ci

#gitlab #gitlab-ci

Вопрос:

Как вы видите ниже, у меня есть два этапа.

1- Сборка

2- Развертывание

И у меня есть 3 вида ветвей

1- мастер

2- тест

3- Другие ветки, созданные разработчиками. (Разработка)

Я хочу запустить сборку для всех ветвей, но у меня есть условие для развертывания

1- Если ветвь является тестовым запуском, развертывание.

2- Если ветвь — это другие ветви, не запускайте развертывание.

3- если ветвь является главной, запускайте развертывание только вручную.

Но эти три условия не работают должным образом с моим gitlab-ci.yml

 stages:
  - build
  - deploy
default:
  image: node:latest

  before_script:
    - |
      if [ "$CI_BUILD_REF_NAME" == "master" ]; then
          ENV="prod"
      elif [ "$CI_BUILD_REF_NAME" == "test" ]; then
          ENV="test"
      else
          ENV="dev"
      fi
    - npm install

build:
  stage: build
  script:
    - cp ./src/env-${ENV}.js ./src/env.js
    - npm run build-compressed

deploy:
  stage: deploy
  rules: //this section doesn't work properly
    - if: '$ENV == "test"'
      when: always
    - if: '$ENV == "prod"'
      when: manual
    - when: never
  script:
    - cp ./src/env-${ENV}.js ./src/env.js
    - npm run build-compressed
    - npm run publish:${ENV}
 

Ответ №1:

Я рекомендую выполнять такое разграничение с помощью правил. Поскольку вы можете легко переопределить переменные с помощью правил, см. Документ GitLab CI .

Ниже вы можете найти короткий пример

 rules
- if: $CI_COMMIT_BRANCH =~ /test/
  variables:                              # Override ENV defined
    ENV: "test"  # at the job level.
- if: $CI_COMMIT_BRANCH =~ /master/
  variables:                              # Override ENV defined
    ENV: "prod"  # at the job level.
- variables: # not 100% sure about this one, as when can stand without a if clause, i assume variables can too :D
    ENV: "dev" 
 

Кроме того, я бы также выполнил проверку правил на основе ветки на этапе развертывания. — поскольку легче проверить ветвь, чем на более позднем этапе убедиться, что переменная Env по-прежнему установлена правильно.

Также важно отметить порядок вычисления. Тот факт, что в before_script разделе по умолчанию есть a, не означает, что он оценивается только один раз для всего. Вычисляется before_script один раз за задание.

Кроме того, правила оцениваются перед выполнением ЗАДАНИЯ, поскольку необходимо определить, следует ли выполнять задание или нет. Это означает, что вы не можете ссылаться на переменную из before_script .

Если вы хотите передать переменную из первого задания во второе задание, вам необходимо сохранить ее в артефакте dotenv — таким образом, переменные будут доступны до начала второго этапа. (Я все еще не уверен, можете ли вы использовать их для оценки в правилах, это то, что вам нужно проверить)

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

Комментарии:

1. Спасибо за ваш ответ, но ошибки в переменных нет. У меня не работает условие, которое запускает развертывание: -> этап: развертывание -> правила: у вас есть идея по этому поводу?

2. я не уверен на 100%, что они будут успешно перенесены на следующий этап. следовательно, я рекомендую использовать правила, чем предыдущий сценарий. Если вы хотите передать переменную env, у вас должен быть артефакт dotenv ( docs.gitlab.com/ee/ci/pipelines /… ) — и они будут использоваться автоматически. Я предполагаю, что переменная env в сценарии before вычисляется слишком поздно. После проверки правил, и он не переносится на следующий этап автоматически

3. docs.gitlab.com/ee/ci/variables/…

4. Я уверен, что переменная ENV переносится в раздел развертывания, потому что, когда я использую echo, я вижу ENV как тест.

5. сценарий before выполняется перед каждым заданием, а не перед всем конвейером, поэтому переменная env присутствует в вашем задании