Не удается разделить значение глобальной переменной между заданиями в файле gitlab ci yaml - PullRequest
0 голосов
/ 22 октября 2018

Я пытаюсь создать приложение, используя gitlab ci.

Имя сгенерированного файла зависит от времени, в этом формате

DEV_APP_yyyyMMddhhmm

(пример: DEV_APP_201810221340, что соответствует дате сегодняшнего дня 2018/10/22 13h40).

Как сохранить это имя в глобальной переменной внутри .gitlab-ci.ymlfile?

Вот мой файл .gitlab-ci.yml:

image: docker:latest
image: docker:latest
services:
- docker:dind

variables:
  DOCKER_DRIVER: overlay
  SPRING_PROFILES_ACTIVE: gitlab-ci
#   TIME: ""
#  BRANCH: ""
#  REC_BUILD_NAME: ""
  TIME: "timex"
  BRANCH: "branchx"
  DEV_BUILD_NAME: "DEV_APP_x"

stages:
- preparation
- build
- package
- deploy
- manual_rec_build
- manual_rec_package

job_preparation:
  stage: preparation
  script:
  - echo ${TIME}
  - export TIME=$(date +%Y%m%d%H%M)
  - "BRANCH=$(echo $CI_BUILD_REF_SLUG | sed 's/[^[[:alnum:]]/_/g')"
  - "DEV_BUILD_NAME=DEV_APP_${BRANCH}_${TIME}"
  - echo ${TIME}

maven-build:
  image: maven:3-jdk-8
  stage: build
  script:
  - echo ${TIME}
  - "mvn package -B"
  artifacts:
paths:
    - target/*.jar
  only:
  - merge-requests
  - /^feature\/sprint.*$/
  - /^DEV_.*$/
#  when: manual


docker-build:
  stage: package
  script:
  - echo ${TIME}
  - docker build -t registry.gitlab.com/mourad.sellam/actuator-simple .
  - docker login -u gitlab-ci-token -p $CI_BUILD_TOKEN registry.gitlab.com
  - docker push registry.gitlab.com/mourad.sellam/actuator-simple
  only:
  - merge-requests
  - /^feature\/sprint.*$/
  - /^DEV_.*$/
  when: manual

    k8s-deploy-production:
  image: google/cloud-sdk
  stage: deploy
  script:
  - echo ${TIME}
  - echo "$GOOGLE_KEY" > key.json
  - gcloud auth activate-service-account --key-file key.json
  - gcloud config set compute/zone europe-west1-c
  - gcloud config set project actuator-sample
  - gcloud config set container/use_client_certificate True
  - gcloud container clusters get-credentials actuator-example
  - kubectl delete secret registry.gitlab.com
  - kubectl create secret docker-registry registry.gitlab.com --docker-server=https://registry.gitlab.com --docker-username=myUserName--docker-password=$REGISTRY_PASSWD --docker-email=myEmail@gmail.com
  - kubectl apply -f deployment.yml --namespace=production
  environment:
    name: production
    url: https://example.production.com
  when: manual

job_manual_rec_build:
  image: maven:3-jdk-8
  stage: manual_rec_build
  script:
  - echo ${TIME}
  - "mvn package -B"
  artifacts:
    paths:
    - target/*.jar
  when: manual
    #   allow_failure: false

job_manual_rec_package:
  stage: manual_rec_package
  variables:
  script:
    - echo ${TIME}
  - echo ${DEV_BUILD_NAME}
  - docker build -t registry.gitlab.com/mourad.sellam/actuator-simple:${DEV_BUILD_NAME} .
  - docker login -u gitlab-ci-token -p $CI_BUILD_TOKEN registry.gitlab.com
- docker push registry.gitlab.com/mourad.sellam/actuator-simple
  artifacts:
    paths:
    - target/*.jar
  when: on_success
  #test 1

Когда я звоню

echo ${TIME}

Отображается «timex».

эхо не удалось

Не могли бы вы рассказать, как хранить глобальную переменную и устанавливать ее в каждом задании?

Ответы [ 2 ]

0 голосов
/ 21 мая 2019

Вы можете использовать артефакты для передачи данных между заданиями.Вот пример из Flant для проверки предыдущего ручного решения конвейера:

approve:
  script:
    - mkdir -p .ci_status
    - echo $(date +%s) > .ci_status/approved
  artifacts:
    paths:
      - .ci_status/

NOT approve:
  script:
    - mkdir -p .ci_status
    - echo $(date +%s) > .ci_status/not_approved
  artifacts:
    paths:
      - .ci_status/

deploy to production:
  script:
    - if [[ $(cat .ci_status/not_approved) > $(cat .ci_status/approved) ]]; then echo "Need approve from release engineer!"; exit 1; fi
    - echo "deploy to production!"
0 голосов
/ 22 октября 2018

Существует открытая проблема 47517 «Передача переменных между заданиями» на Gitlab CE.

CI / CD часто нуждается в передаче информации от одного задания к другому, и артефакты могутиспользовать для этого, хотя это тяжелое решение с непреднамеренными побочными эффектами.Рабочие пространства - это еще одно предложение для передачи файлов между заданиями.Но иногда вы вообще не хотите передавать файлы, только небольшую часть данных.

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

...