GitLab CI: 6 Funktionen aus den neuesten Versionen, auf die wir gewartet haben

№1: needs

• job'.
• GitLab: 12.2.
• .

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

Nr. 2: erstreckt sich

• Verbesserte YAML-Anker und Aliase.
• Eingeführt seit 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"

Nr. 3: einschließen

• Wir teilen riesige YAML in mehrere und verwenden sie in anderen Projekten wieder.
• Eingeführt in Core seit Version 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

• using include: file - Include GitLab CI-Dateien aus einem anderen Repository derselben GitLab-Instanz.
• mit include: template - Sammlungen vorgefertigter GitLab-Vorlagen ,
• mit include: remote - eine externe Datei (über HTTPS zugänglich).

Nr. 4: nur / außer refs

• Umfassende Bedingungen, einschließlich Variablen und Dateiänderungen.
• Da es sich um eine ganze Familie von Funktionen handelt, wurden einige Teile in GitLab 10.0 angezeigt, während andere (z. B. changes) in 11.4 angezeigt wurden.
• 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"

Nr. 5: Regeln

• Individuelle Jobregeln.
• Eingeführt in GitLab 12.3.
• docs.gitlab.com/ce/ci/yaml/#rules

# 6: Umgebung: auto_stop_in

• Stoppen Sie Umgebungen ohne Aktivität.
• Eingeführt in GitLab 12.8.
• docs.gitlab.com/ce/ci/yaml/#environmentauto_stop_in

Bonus: temporäre Hütten, wenn nicht genügend Möglichkeiten vorhanden sind

Problemumgehung Nr. 1: Starten Sie zwei Jobs mit einer Schaltfläche

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"

Problemumgehung Nr. 2: Übertragung in MR-RB-Dateien für Rubocop im Bild geändert

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}

Problemumgehung Nr. 3: Auslöser zum Starten von Jobs aus anderen Repositorys beim Rollout

  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"

• Job on Trigger ist so konzipiert, dass eine Variable an die API übergeben wird, ähnlich wie in Beispiel Nr. 1. Es ist logischer, dies auf der API mit dem übergebenen Jobnamen zu implementieren.
• Ja, die Funktion ist in der kommerziellen (EE) Version von GitLab enthalten, wird jedoch nicht berücksichtigt.

Fazit

PS

• " Montage und Bereitstellung der gleichen Art von Microservices mit werf und GitLab CI ";
• " JUnit in GitLab CI mit Kubernetes ";
• «werf — CI/CD Kubernetes ( )» ( ; 27 2019 DevOpsConf);
• « GitLab CI»;
• «GitLab CI production».