GitLab CI: 6 ميزات من أحدث الإصدارات التي ننتظرها

№1: needs

• job'.
• GitLab: 12.2.
• .

  needs:
    - To production (Cluster 1)
    - To production (Cluster 2)

رقم 2: يمتد

• تعزيز المراسي والأسماء المستعارة لـ YAML.
• قدم منذ GitLab 11.3.
• docs.gitlab.com/ce/ci/yaml/#extends

.base_deploy: &base_deploy
  stage: deploy
  script:
    - my_deploy_command.sh
  variables:
    CLUSTER: "default-cluster"
    MY_VAR: "10"

Deploy Test:
  <<: *base_deploy
  environment:
    url: test.example.com
    name: test

Deploy Production:
  <<: *base_deploy
  environment:
    url: production.example.com
    name: production
  variables:
    CLUSTER: "prod-cluster"
    MY_VAR: "10"

.base_deploy: 
  stage: deploy
  script:
    - my_deploy_command.sh
  variables:
    CLUSTER: "default-cluster"
    MY_VAR: "10"

Deploy Production:
  extends: .base_deploy
  environment:
    url: production.example.com
    name: production
  variables:
    CLUSTER: "prod-cluster"

رقم 3: يشمل

• نقسم YAML ضخمة إلى عدة وإعادة استخدامها في مشاريع أخرى.
• تم تقديمه في Core منذ الإصدار 11.4.
• docs.gitlab.com/ce/ci/yaml/#include

stages:
  - test
  - build
  - deploy

variables:
  VAR_FOR_ALL: 42

include:
  - local: .gitlab/ci/test.yml
  - local: .gitlab/ci/build.yml
  - local: .gitlab/ci/deploy-base.yml
  - local: .gitlab/ci/deploy-production.yml

• باستخدام include: file - تضمين ملفات GitLab CI من مستودع آخر لنفس مثيل GitLab ،
• مع : قالب - مجموعات من قوالب GitLab الجاهزة ،
• مع ما يلي: عن بعد - ملف خارجي (يمكن الوصول إليه عبر HTTPS).

رقم 4: فقط / باستثناء المرجع

• شروط شاملة ، بما في ذلك المتغيرات وتغييرات الملف.
• نظرًا لأن هذه مجموعة كاملة من الوظائف ، فقد بدأت بعض الأجزاء في الظهور في GitLab 10.0 ، بينما بدأت أجزاء أخرى (على سبيل المثال changes) في الظهور في 11.4.
• docs.gitlab.com/ce/ci/yaml/#onlyexcept-advanced

Tests:
  only:
    - master
  except:
    refs:
    - schedules
    - triggers
    variables:
    - $CI_COMMIT_MESSAGE =~ /skip tests/

  only:
    refs:
      - master
      - merge_requests
    changes:
      - "front/**/*"
      - "jest.config.js"
      - "package.json"

رقم 5: القواعد

• قواعد العمل الفردية.
• المقدمة في GitLab 12.3.
• docs.gitlab.com/ce/ci/yaml/#rules

# 6: البيئة: auto_stop_in

• توقف البيئات في حالة عدم وجود نشاط.
• المقدمة في GitLab 12.8.
• docs.gitlab.com/ce/ci/yaml/#environmentauto_stop_in

المكافأة: أكواخ مؤقتة عندما لا تكون هناك فرص كافية

الحل رقم 1: إطلاق وظيفتين باستخدام زر واحد

script:
  - > 
    export CI_PROD_CL1_JOB_ID=`curl -s -H "PRIVATE-TOKEN: ${GITLAB_API_TOKEN}" \ 
      "https://gitlab.domain/api/v4/projects/${CI_PROJECT_ID}/pipelines/${CI_PIPELINE_ID}/jobs" | \
      jq '[.[] | select(.name == "Deploy (Cluster 1)")][0] | .id'`
  - > 
    export CI_PROD_CL2_JOB_ID=`curl -s -H "PRIVATE-TOKEN: ${GITLAB_API_TOKEN}" \ 
      "https://gitlab.domain/api/v4/projects/${CI_PROJECT_ID}/pipelines/${CI_PIPELINE_ID}/jobs" | \
      jq '[.[] | select(.name == "Deploy (Cluster 2)")][0] | .id'`
  - > 
    curl -s --request POST -H "PRIVATE-TOKEN: ${GITLAB_API_TOKEN}" \ 
      "https://gitlab.domain/api/v4/projects/${CI_PROJECT_ID}/jobs/$CI_PROD_CL1_JOB_ID/play"
  - > 
    curl -s --request POST -H "PRIVATE-TOKEN: ${GITLAB_API_TOKEN}" \ 
      "https://gitlab.domain/api/v4/projects/${CI_PROJECT_ID}/jobs/$CI_PROD_CL2_JOB_ID/play"

الحل رقم 2: تم تغيير النقل في ملفات MR rb لـ rubocop داخل الصورة

Rubocop:
  stage: test
  allow_failure: false
  script:
    ...
    - export VARFILE=$(mktemp)
    - export MASTERCOMMIT=$(git merge-base origin/master HEAD)
    - echo -ne 'CHANGED_FILES=' > ${VARFILE}
    - if [ $(git --no-pager diff --name-only ${MASTERCOMMIT} | grep '.rb$' | wc -w |awk '{print $1}') -gt 0 ]; then
        git --no-pager diff --name-only ${MASTERCOMMIT} | grep '.rb$' |tr '\n' ' ' >> ${VARFILE} ;
      fi
    - if [ $(wc -w ${VARFILE} | awk '{print $1}') -gt 1 ]; then
        werf --stages-storage :local run rails-dev --docker-options="--rm --user app --env-file=${VARFILE}" -- bash -c /scripts/rubocop.sh ;
      fi
    - rm ${VARFILE}

الحل # 3: بدء تشغيل المهام من مستودعات أخرى عند طرحها

  before_script:
    - |
      echo '### Trigger review: infra'
      curl -s -X POST \
        -F "token=$REVIEW_TOKEN_INFRA" \
        -F "ref=master" \
        -F "variables[REVIEW_NS]=$CI_ENVIRONMENT_SLUG" \
        -F "variables[ACTION]=auto_review_start" \
        https://gitlab.example.com/api/v4/projects/${INFRA_PROJECT_ID}/trigger/pipeline

  only:
    refs:
    - triggers
    variables:
    - $ACTION == "auto_review_start"

• تم تصميم الوظيفة عند التشغيل لتكون مرتبطة بتمرير متغير إلى واجهة برمجة التطبيقات ، على غرار المثال رقم 1. من المنطقي أكثر تنفيذ ذلك على API مع تمرير اسم المهمة.
• نعم ، الوظيفة موجودة في الإصدار التجاري (EE) من GitLab ، لكننا لا نعتبرها.

استنتاج

ملاحظة

• " تجميع ونشر نفس النوع من الخدمات الدقيقة مع werf و GitLab CI " ؛
• " JUnit في GitLab CI مع Kubernetes " ؛
• «werf — CI/CD Kubernetes ( )» ( ; 27 2019 DevOpsConf);
• « GitLab CI»;
• «GitLab CI production».