ProHoster > Блог > administratio > JUnit in GitLab CI apud Kubernetes

JUnit in GitLab CI apud Kubernetes

Quamvis omnes probe probe noverint quod programmata tua tentantes magnum et necessarium sit, et multi automatice eam diu fecerint, in magnitudine Habr non fuit una recipe ad constituendum complexionem talis popularis productorum in hoc angulus sicut (noster ventus) GitLab et JUnit. Lacunam hanc impleamus!

JUnit in GitLab CI apud Kubernetes

Introductory

Primum, ut demus aliquem contextum;

  • Cum omnes applicationes nostrae in Kubernetes currunt, probationes currentes considerabimus de infrastructura convenienti.
  • Ad ecclesiam et instruere utimur werf * (per terminos infrastructuras, hoc etiam automatice significat Helm involvi).
  • Non ingrediar in singula actualis creationis testium: in casu nostro, cliens ipse probat se scribens, et nos tantum incussum (et praesentiam debitae relationis in rogatione merge).


Quid erit generalis series actionum simile?

  1. Ad applicationem aedificationis - descriptionem huius scaenae omittemus.
  2. Explica applicationem ad spatium spatii separati Botri Kubernetarum et tentationis initium.
  3. Quaerendo artificia et parsing JUnit refert cum GitLab.
  4. Deletis antea spatiis nominalibus creatum est.

Nunc - ad exsecutionem!

tionibus

C. GitLab

Sit scriptor satus cum fragmento .gitlab-ci.yamlest, qui applicationes et cursus probat explicandi describit. Enumeratio satis voluminosa evasit, ita cum commentis satis suppleta est;

variables:
# объявляем версию werf, которую собираемся использовать
  WERF_VERSION: "1.0 beta"

.base_deploy: &base_deploy
  script:
# создаем namespace в K8s, если его нет
    - kubectl --context="${WERF_KUBE_CONTEXT}" get ns ${CI_ENVIRONMENT_SLUG} || kubectl create ns ${CI_ENVIRONMENT_SLUG}
# загружаем werf и деплоим — подробнее об этом см. в документации
# (https://werf.io/how_to/gitlab_ci_cd_integration.html#deploy-stage)
    - type multiwerf && source <(multiwerf use ${WERF_VERSION})
    - werf version
    - type werf && source <(werf ci-env gitlab --tagging-strategy tag-or-branch --verbose)
    - werf deploy --stages-storage :local
      --namespace ${CI_ENVIRONMENT_SLUG}
      --set "global.commit_ref_slug=${CI_COMMIT_REF_SLUG:-''}"
# передаем переменную `run_tests`
# она будет использоваться в рендере Helm-релиза
      --set "global.run_tests=${RUN_TESTS:-no}"
      --set "global.env=${CI_ENVIRONMENT_SLUG}"
# изменяем timeout (бывают долгие тесты) и передаем его в релиз
      --set "global.ci_timeout=${CI_TIMEOUT:-900}"
     --timeout ${CI_TIMEOUT:-900}
  dependencies:
    - Build

.test-base: &test-base
  extends: .base_deploy
  before_script:
# создаем директорию для будущего отчета, исходя из $CI_COMMIT_REF_SLUG
    - mkdir /mnt/tests/${CI_COMMIT_REF_SLUG} || true
# вынужденный костыль, т.к. GitLab хочет получить артефакты в своем build-dir’е
    - mkdir ./tests || true
    - ln -s /mnt/tests/${CI_COMMIT_REF_SLUG} ./tests/${CI_COMMIT_REF_SLUG}
  after_script:
# после окончания тестов удаляем релиз вместе с Job’ом
# (и, возможно, его инфраструктурой)
    - type multiwerf && source <(multiwerf use ${WERF_VERSION})
    - werf version
    - type werf && source <(werf ci-env gitlab --tagging-strategy tag-or-branch --verbose)
    - werf dismiss --namespace ${CI_ENVIRONMENT_SLUG} --with-namespace
# мы разрешаем падения, но вы можете сделать иначе
  allow_failure: true
  variables:
    RUN_TESTS: 'yes'
# задаем контекст в werf
# (https://werf.io/how_to/gitlab_ci_cd_integration.html#infrastructure)
    WERF_KUBE_CONTEXT: 'admin@stage-cluster'
  tags:
# используем раннер с тегом `werf-runner`
    - werf-runner
  artifacts:
# требуется собрать артефакт для того, чтобы его можно было увидеть
# в пайплайне и скачать — например, для более вдумчивого изучения
    paths:
      - ./tests/${CI_COMMIT_REF_SLUG}/*
# артефакты старше недели будут удалены
    expire_in: 7 day
# важно: эти строки отвечают за парсинг отчета GitLab’ом
    reports:
      junit: ./tests/${CI_COMMIT_REF_SLUG}/report.xml

# для упрощения здесь показаны всего две стадии
# в реальности же у вас их будет больше — как минимум из-за деплоя
stages:
  - build
  - tests

build:
  stage: build
  script:
# сборка — снова по документации по werf
# (https://werf.io/how_to/gitlab_ci_cd_integration.html#build-stage)
    - type multiwerf && source <(multiwerf use ${WERF_VERSION})
    - werf version
    - type werf && source <(werf ci-env gitlab --tagging-strategy tag-or-branch --verbose)
    - werf build-and-publish --stages-storage :local
  tags:
    - werf-runner
  except:
    - schedules

run tests:
  <<: *test-base
  environment:
# "сама соль" именования namespace’а
# (https://docs.gitlab.com/ce/ci/variables/predefined_variables.html)
    name: tests-${CI_COMMIT_REF_SLUG}
  stage: tests
  except:
    - schedules

Kubernetes

Nunc in indicem .helm/templates YAML faciamus cum Job - tests-job.yaml — currere probationes et facultates quibus Kubernetes indiget. Vide explicationes post enumerationem:

{{- if eq .Values.global.run_tests "yes" }}
---
apiVersion: v1
kind: ConfigMap
metadata:
  name: tests-script
data:
  tests.sh: |
    echo "======================"
    echo "${APP_NAME} TESTS"
    echo "======================"

    cd /app
    npm run test:ci
    cp report.xml /app/test_results/${CI_COMMIT_REF_SLUG}/

    echo ""
    echo ""
    echo ""

    chown -R 999:999 /app/test_results/${CI_COMMIT_REF_SLUG}
---
apiVersion: batch/v1
kind: Job
metadata:
  name: {{ .Chart.Name }}-test
  annotations:
    "helm.sh/hook": post-install,post-upgrade
    "helm.sh/hook-weight": "2"
    "werf/watch-logs": "true"
spec:
  activeDeadlineSeconds: {{ .Values.global.ci_timeout }}
  backoffLimit: 1
  template:
    metadata:
      name: {{ .Chart.Name }}-test
    spec:
      containers:
      - name: test
        command: ['bash', '-c', '/app/tests.sh']
{{ tuple "application" . | include "werf_container_image" | indent 8 }}
        env:
        - name: env
          value: {{ .Values.global.env }}
        - name: CI_COMMIT_REF_SLUG
          value: {{ .Values.global.commit_ref_slug }}
       - name: APP_NAME
          value: {{ .Chart.Name }}
{{ tuple "application" . | include "werf_container_env" | indent 8 }}
        volumeMounts:
        - mountPath: /app/test_results/
          name: data
        - mountPath: /app/tests.sh
          name: tests-script
          subPath: tests.sh
      tolerations:
      - key: dedicated
        operator: Exists
      - key: node-role.kubernetes.io/master
        operator: Exists
      restartPolicy: OnFailure
      volumes:
      - name: data
        persistentVolumeClaim:
          claimName: {{ .Chart.Name }}-pvc
      - name: tests-script
        configMap:
          name: tests-script
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: {{ .Chart.Name }}-pvc
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 10Mi
  storageClassName: {{ .Chart.Name }}-{{ .Values.global.commit_ref_slug }}
  volumeName: {{ .Values.global.commit_ref_slug }}

---
apiVersion: v1
kind: PersistentVolume
metadata:
  name: {{ .Values.global.commit_ref_slug }}
spec:
  accessModes:
  - ReadWriteOnce
  capacity:
    storage: 10Mi
  local:
    path: /mnt/tests/
  nodeAffinity:
   required:
     nodeSelectorTerms:
     - matchExpressions:
       - key: kubernetes.io/hostname
         operator: In
         values:
         - kube-master
  persistentVolumeReclaimPolicy: Delete
  storageClassName: {{ .Chart.Name }}-{{ .Values.global.commit_ref_slug }}
{{- end }}

Quales opes? in hac configuratione descriptus? Cum disponimus, singula nomina spatii ad propositum creamus (hoc in "indicio est" .gitlab-ci.yaml - tests-${CI_COMMIT_REF_SLUG}) Et volvuntur eum:

  1. ConfigMap cum test script;
  2. Job descriptione vasculi praefinitum directivum commandquae mox probat;
  3. PV et PVC, quae te condere testi data .

Attende ad condicionem introductoriam cum if in principio manifesti - proinde alia YAML tabulae chartulae Helm cum applicatione involvenda sunt novis consilio ita ut in probatione non instruantur. Ille est:

{{- if ne .Values.global.run_tests "yes" }}
---
я другой ямлик
{{- end }}

Sed si probat infrastructure aliqua eget (exempli gratia Redis, RabbitMQ, Mongo, PostgreSQL...) - possunt esse eorum YAMLs non averte. Eas in ambitus quoque enucleando explicas... componit, ut tibi videbitur, nimirum.

ultima tactus

Quod ecclesiam et instruere utens werf operatur in nunc tantum in servo constructo (cum gitlab-cursore), et vasculum cum probatis in dominum immittitur, opus directorium creare /mnt/tests dominum et da cursori; exempli gratia per NFS. Singula exempla cum explanationibus reperiri possunt K8s documenta.

Fiet;

user@kube-master:~$ cat /etc/exports | grep tests
/mnt/tests    IP_gitlab-builder/32(rw,nohide,insecure,no_subtree_check,sync,all_squash,anonuid=999,anongid=998)

user@gitlab-runner:~$ cat /etc/fstab | grep tests
IP_kube-master:/mnt/tests    /mnt/tests   nfs4    _netdev,auto  0       0

Nemo vetat facere NFS cursorem directe participare in gitlab, et deinde in siliquas ascendere.

illud

Quaeris cur inpedias omnia creando Iob si simpliciter currere potes scripturam cum probationibus directe in testa cursoris? Responsum est leve...

Nonnullae probationes accessum requirunt ad infrastructuram (MongoDB, RabbitMQ, PostgreSQL, etc.) ad comprobandum se recte operari. Tentantes unitatem facimus - cum hac accessione facile fit huiusmodi additamenta includere. Adde quod hoc obtinemus vexillum accessum instruere (etiamsi NFS utens, additis directoriis escendendis).

exitum

Quid videbimus cum figurationem praeparatam applicabimus?

In merge petitionem summatim mutant pro probationibus currunt in pipelino recentissimo ostendet:

JUnit in GitLab CI apud Kubernetes

Quisque error hic deprimi potest ad singula:

JUnit in GitLab CI apud Kubernetes

NB: Attentus lector animadvertet nos applicationem NodeJS tentare, et in eenshotsscray - .NET... Nolite mirari: iustum est quod, dum articulum paramus, nulli errores in probatione primae applicationis inveniuntur, sed illi. in alio reperti sunt.

conclusio,

Ut vides, nihil complicatum!

Principio, si concham collectorem iam habes et facit, sed Kubernetes non indiges, experimento magis simplicior erit quam hic descriptus. Et in GitLab CI documenta exempla invenies pro Ruby, Vade, Gradle, Maven et nonnullis aliis.

PS

Lege etiam in nostro diario:

Source: www.habr.com

Add a comment