🥇GitLab CI 中的 JUnit 與 Kubernetes

儘管每個人都清楚地知道測試軟體是重要且必要的，並且許多人長期以來一直自動進行測試，但在浩瀚的 Habr 中，沒有一個單一的方法可以在其中設置此類流行產品的組合。這個利基市場是（我們最喜歡的）GitLab 和JUnit。讓我們來填補這個空白吧！

介紹

首先，讓我提供一些背景資訊：

由於我們所有的應用程式都在 Kubernetes 上運行，因此我們將考慮在適當的基礎架構上運行測試。
對於組裝和部署，我們使用韋爾夫（就基礎設施組件而言，這也自動意味著 Helm 的參與）。
我不會詳細討論實際創建測試的細節：在我們的例子中，客戶自己編寫測試，我們只確保它們的啟動（以及合併請求中存在相應的報告）。

一般的行動順序會是什麼樣子？

建立應用程式 - 我們將省略此階段的描述。
將應用程式部署到 Kubernetes 叢集的單獨命名空間並開始測試。
使用 GitLab 搜尋工件並解析 JUnit 報告。
刪除先前建立的命名空間。

現在－實施！

調整

亞搏體育app CI

讓我們從一個片段開始 .gitlab-ci.yaml，它描述了部署應用程式和運行測試。清單內容相當龐大，因此補充了完整的評論：

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

現在在目錄中 .helm/templates 讓我們使用 Job 建立 YAML - tests-job.yaml — 執行測試及其所需的 Kubernetes 資源。請參閱列表後的說明：

{{- 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 }}

什麼樣的資源 在此配置中描述？部署時，我們為專案創建一個唯一的命名空間（這在 .gitlab-ci.yaml - tests-${CI_COMMIT_REF_SLUG}）並推出：

配置映射表 帶有測試腳本；
約伯記‬ 包含 pod 的描述和指定的指令 command，它只運行測試；
光伏和聚氯乙烯，允許您儲存測試資料。

注意介紹條件 if 在清單的開頭 - 因此，帶有應用程式的 Helm 圖表的其他 YAML 檔案必須包裝在撤銷設計時應確保它們在測試期間不會部署。那是：

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

然而，如果測試 需要一些基礎設施 （例如，Redis、RabbitMQ、Mongo、PostgreSQL...） - 它們的 YAML 可以是沒有關。也將它們部署到測試環境中......當然，根據您的需求調整它們。

最後的觸摸

因為目前可以使用 werf 進行組裝和部署僅在建置伺服器上（使用 gitlab-runner），並且帶有測試的 pod 在 master 上啟動，您將需要建立目錄 /mnt/tests 放在主人身上並交給跑者， 例如，透過 NFS。帶有解釋的詳細示例可以在 K8s文檔.

結果將是：

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

沒有人禁止直接在 gitlab-runner 上進行 NFS 共享，然後將其掛載到 pod 中。

注意

您可能會問，如果您可以直接在 shell 運行器上執行帶有測試的腳本，為什麼要透過建立作業來使一切變得複雜？答案很簡單…

一些測試需要存取基礎設施（MongoDB、RabbitMQ、PostgreSQL 等）以驗證它們是否正常運作。我們使測試統一 - 透過這種方法，可以輕鬆包含此類附加實體。除此之外，我們還得到標準部署方式（即使使用NFS，額外掛載目錄）。

導致

當我們應用準備好的配置時，我們會看到什麼？

合併請求將顯示在其最新管道中運行的測試的摘要統計資料：

每個錯誤可以點擊此處查看詳細資訊：

NB：細心的讀者會注意到我們正在測試一個 NodeJS 應用程序，並且在屏幕截圖中 - .NET...不要感到驚訝：作為文章準備的一部分，在測試第一個應用程序時沒有發現錯誤，但他們是在另一個地方被發現的。

結論

正如您所看到的，沒什麼複雜的！

原則上，如果您已經有一個 shell 收集器並且它可以工作，但您不需要 Kubernetes，那麼對其進行測試將比此處描述的任務更簡單。並且在亞搏體育appGitLab CI文檔您會找到 Ruby、Go、Gradle、Maven 等範例。

聚苯乙烯

另請閱讀我們的博客：

來源： www.habr.com

GitLab CI 中的 JUnit 與 Kubernetes

介紹

調整

亞搏體育app CI

Kubernetes

最後的觸摸

注意

導致

結論

聚苯乙烯

添加評論 取消回复

添加評論取消回复