ਕੁਬਰਨੇਟਸ ਦੇ ਨਾਲ GitLab CI ਵਿੱਚ JUnit

ਇਸ ਤੱਥ ਦੇ ਬਾਵਜੂਦ ਕਿ ਹਰ ਕੋਈ ਚੰਗੀ ਤਰ੍ਹਾਂ ਜਾਣਦਾ ਹੈ ਕਿ ਤੁਹਾਡੇ ਸੌਫਟਵੇਅਰ ਦੀ ਜਾਂਚ ਕਰਨਾ ਮਹੱਤਵਪੂਰਨ ਅਤੇ ਜ਼ਰੂਰੀ ਹੈ, ਅਤੇ ਬਹੁਤ ਸਾਰੇ ਇਸਨੂੰ ਲੰਬੇ ਸਮੇਂ ਤੋਂ ਆਪਣੇ ਆਪ ਹੀ ਕਰ ਰਹੇ ਹਨ, ਹੈਬਰ ਦੀ ਵਿਸ਼ਾਲਤਾ ਵਿੱਚ ਅਜਿਹੇ ਪ੍ਰਸਿੱਧ ਉਤਪਾਦਾਂ ਦੇ ਸੁਮੇਲ ਨੂੰ ਸਥਾਪਤ ਕਰਨ ਲਈ ਇੱਕ ਵੀ ਵਿਅੰਜਨ ਨਹੀਂ ਸੀ। ਇਹ ਸਥਾਨ (ਸਾਡਾ ਮਨਪਸੰਦ) GitLab ਅਤੇ JUnit। ਆਓ ਇਸ ਪਾੜੇ ਨੂੰ ਭਰੀਏ!

ਜਾਣ-ਪਛਾਣ

ਪਹਿਲਾਂ, ਮੈਨੂੰ ਕੁਝ ਸੰਦਰਭ ਦੇਣ ਦਿਓ:

• ਕਿਉਂਕਿ ਸਾਡੀਆਂ ਸਾਰੀਆਂ ਐਪਲੀਕੇਸ਼ਨਾਂ ਕੁਬਰਨੇਟਸ 'ਤੇ ਚੱਲਦੀਆਂ ਹਨ, ਅਸੀਂ ਉਚਿਤ ਬੁਨਿਆਦੀ ਢਾਂਚੇ 'ਤੇ ਟੈਸਟਾਂ ਨੂੰ ਚਲਾਉਣ ਬਾਰੇ ਵਿਚਾਰ ਕਰਾਂਗੇ।
• ਅਸੈਂਬਲੀ ਅਤੇ ਤੈਨਾਤੀ ਲਈ ਅਸੀਂ ਵਰਤਦੇ ਹਾਂ werf (ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਦੇ ਹਿੱਸੇ ਦੇ ਰੂਪ ਵਿੱਚ, ਇਸਦਾ ਆਪਣੇ ਆਪ ਹੀ ਮਤਲਬ ਹੈ ਕਿ ਹੈਲਮ ਸ਼ਾਮਲ ਹੈ)।
• ਮੈਂ ਟੈਸਟਾਂ ਦੀ ਅਸਲ ਰਚਨਾ ਦੇ ਵੇਰਵਿਆਂ ਵਿੱਚ ਨਹੀਂ ਜਾਵਾਂਗਾ: ਸਾਡੇ ਕੇਸ ਵਿੱਚ, ਕਲਾਇੰਟ ਖੁਦ ਟੈਸਟ ਲਿਖਦਾ ਹੈ, ਅਤੇ ਅਸੀਂ ਸਿਰਫ ਉਹਨਾਂ ਦੀ ਸ਼ੁਰੂਆਤ ਨੂੰ ਯਕੀਨੀ ਬਣਾਉਂਦੇ ਹਾਂ (ਅਤੇ ਅਭੇਦ ਦੀ ਬੇਨਤੀ ਵਿੱਚ ਇੱਕ ਅਨੁਸਾਰੀ ਰਿਪੋਰਟ ਦੀ ਮੌਜੂਦਗੀ)।

ਕਾਰਵਾਈਆਂ ਦਾ ਆਮ ਕ੍ਰਮ ਕਿਹੋ ਜਿਹਾ ਦਿਖਾਈ ਦੇਵੇਗਾ?

1. ਐਪਲੀਕੇਸ਼ਨ ਬਣਾਉਣਾ - ਅਸੀਂ ਇਸ ਪੜਾਅ ਦੇ ਵਰਣਨ ਨੂੰ ਛੱਡ ਦੇਵਾਂਗੇ।
2. ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਕੁਬਰਨੇਟਸ ਕਲੱਸਟਰ ਦੇ ਇੱਕ ਵੱਖਰੇ ਨੇਮਸਪੇਸ ਵਿੱਚ ਤੈਨਾਤ ਕਰੋ ਅਤੇ ਜਾਂਚ ਸ਼ੁਰੂ ਕਰੋ।
3. ਕਲਾਤਮਕ ਚੀਜ਼ਾਂ ਦੀ ਖੋਜ ਕਰਨਾ ਅਤੇ GitLab ਨਾਲ JUnit ਰਿਪੋਰਟਾਂ ਨੂੰ ਪਾਰਸ ਕਰਨਾ।
4. ਪਹਿਲਾਂ ਬਣਾਇਆ ਨਾਮ-ਸਥਾਨ ਮਿਟਾਉਣਾ।

ਹੁਣ - ਲਾਗੂ ਕਰਨ ਲਈ!

ਵਿਵਸਥਾ

ਗਿੱਟਲਾਬ ਸੀ.ਆਈ.

ਆਉ ਇੱਕ ਟੁਕੜੇ ਨਾਲ ਸ਼ੁਰੂ ਕਰੀਏ .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

ਕਬਰਨੇਟਿਸ

ਹੁਣ ਡਾਇਰੈਕਟਰੀ ਵਿੱਚ .helm/templates ਆਓ ਜੌਬ ਨਾਲ YAML ਬਣਾਈਏ - tests-job.yaml — ਟੈਸਟਾਂ ਅਤੇ ਕੁਬਰਨੇਟਸ ਸਰੋਤਾਂ ਨੂੰ ਚਲਾਉਣ ਲਈ ਇਸਦੀ ਲੋੜ ਹੈ। ਸੂਚੀਬੱਧ ਕਰਨ ਤੋਂ ਬਾਅਦ ਸਪੱਸ਼ਟੀਕਰਨ ਵੇਖੋ:

{{- 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}) ਅਤੇ ਇਸਨੂੰ ਰੋਲ ਆਊਟ ਕਰੋ:

1. ConfigMap ਟੈਸਟ ਸਕ੍ਰਿਪਟ ਦੇ ਨਾਲ;
2. ਅੱਯੂਬ ਪੌਡ ਦੇ ਵਰਣਨ ਅਤੇ ਨਿਰਧਾਰਤ ਨਿਰਦੇਸ਼ਾਂ ਦੇ ਨਾਲ command, ਜੋ ਸਿਰਫ ਟੈਸਟ ਚਲਾਉਂਦਾ ਹੈ;
3. ਪੀਵੀ ਅਤੇ ਪੀਵੀਸੀ, ਜੋ ਤੁਹਾਨੂੰ ਟੈਸਟ ਡੇਟਾ ਸਟੋਰ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ।

ਦੇ ਨਾਲ ਸ਼ੁਰੂਆਤੀ ਸਥਿਤੀ ਵੱਲ ਧਿਆਨ ਦਿਓ if ਮੈਨੀਫੈਸਟ ਦੇ ਸ਼ੁਰੂ ਵਿੱਚ - ਇਸਦੇ ਅਨੁਸਾਰ, ਐਪਲੀਕੇਸ਼ਨ ਦੇ ਨਾਲ ਹੈਲਮ ਚਾਰਟ ਦੀਆਂ ਹੋਰ YAML ਫਾਈਲਾਂ ਨੂੰ ਲਪੇਟਿਆ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ ਉਲਟਾ ਡਿਜ਼ਾਇਨ ਤਾਂ ਜੋ ਉਹ ਟੈਸਟਿੰਗ ਦੌਰਾਨ ਤਾਇਨਾਤ ਨਾ ਹੋਣ। ਜੋ ਕਿ ਹੈ:

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

ਪਰ, ਜੇਕਰ ਟੈਸਟ ਕੁਝ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਦੀ ਲੋੜ ਹੈ (ਉਦਾਹਰਨ ਲਈ, Redis, RabbitMQ, Mongo, PostgreSQL...) - ਉਹਨਾਂ ਦੇ YAML ਹੋ ਸਕਦੇ ਹਨ ਨਾ ਬੰਦ ਕਰ ਦਿਓ. ਉਹਨਾਂ ਨੂੰ ਇੱਕ ਟੈਸਟ ਵਾਤਾਵਰਨ ਵਿੱਚ ਵੀ ਤੈਨਾਤ ਕਰੋ... ਉਹਨਾਂ ਨੂੰ ਅਨੁਕੂਲ ਬਣਾਓ ਜਿਵੇਂ ਤੁਸੀਂ ਠੀਕ ਸਮਝਦੇ ਹੋ, ਬੇਸ਼ਕ।

ਅੰਤਮ ਛੂਹ

ਕਿਉਂਕਿ ਅਸੈਂਬਲੀ ਅਤੇ ਤੈਨਾਤੀ ਹੁਣ ਲਈ ਵਰਫ ਵਰਕਸ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਸਿਰਫ ਬਿਲਡ ਸਰਵਰ 'ਤੇ (ਗਿਟਲਬ-ਰਨਰ ਦੇ ਨਾਲ), ਅਤੇ ਟੈਸਟਾਂ ਵਾਲਾ ਪੌਡ ਮਾਸਟਰ 'ਤੇ ਲਾਂਚ ਕੀਤਾ ਗਿਆ ਹੈ, ਤੁਹਾਨੂੰ ਇੱਕ ਡਾਇਰੈਕਟਰੀ ਬਣਾਉਣ ਦੀ ਲੋੜ ਹੋਵੇਗੀ। /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

ਕੋਈ ਵੀ ਗਿਟਲੈਬ-ਰਨਰ 'ਤੇ ਸਿੱਧੇ NFS ਸ਼ੇਅਰ ਬਣਾਉਣ, ਅਤੇ ਫਿਰ ਇਸਨੂੰ ਪੌਡਾਂ ਵਿੱਚ ਮਾਊਂਟ ਕਰਨ ਤੋਂ ਮਨ੍ਹਾ ਕਰਦਾ ਹੈ।

ਟਿੱਪਣੀ

ਤੁਸੀਂ ਸ਼ਾਇਦ ਪੁੱਛ ਰਹੇ ਹੋਵੋਗੇ ਕਿ ਜੇ ਤੁਸੀਂ ਸ਼ੈੱਲ ਰਨਰ 'ਤੇ ਸਿੱਧੇ ਟੈਸਟਾਂ ਨਾਲ ਸਕ੍ਰਿਪਟ ਚਲਾ ਸਕਦੇ ਹੋ ਤਾਂ ਨੌਕਰੀ ਬਣਾ ਕੇ ਹਰ ਚੀਜ਼ ਨੂੰ ਕਿਉਂ ਗੁੰਝਲਦਾਰ ਬਣਾਉ? ਜਵਾਬ ਬਹੁਤ ਮਾਮੂਲੀ ਹੈ ...

ਕੁਝ ਟੈਸਟਾਂ ਨੂੰ ਇਹ ਪੁਸ਼ਟੀ ਕਰਨ ਲਈ ਬੁਨਿਆਦੀ ਢਾਂਚੇ (MongoDB, RabbitMQ, PostgreSQL, ਆਦਿ) ਤੱਕ ਪਹੁੰਚ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ ਕਿ ਉਹ ਸਹੀ ਢੰਗ ਨਾਲ ਕੰਮ ਕਰਦੇ ਹਨ। ਅਸੀਂ ਟੈਸਟਿੰਗ ਨੂੰ ਏਕੀਕ੍ਰਿਤ ਬਣਾਉਂਦੇ ਹਾਂ - ਇਸ ਪਹੁੰਚ ਨਾਲ, ਅਜਿਹੀਆਂ ਵਾਧੂ ਇਕਾਈਆਂ ਨੂੰ ਸ਼ਾਮਲ ਕਰਨਾ ਆਸਾਨ ਹੋ ਜਾਂਦਾ ਹੈ। ਇਸ ਤੋਂ ਇਲਾਵਾ, ਅਸੀਂ ਪ੍ਰਾਪਤ ਕਰਦੇ ਹਾਂ ਮਿਆਰੀ ਤੈਨਾਤੀ ਪਹੁੰਚ (ਭਾਵੇਂ NFS ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ, ਡਾਇਰੈਕਟਰੀਆਂ ਦੀ ਵਾਧੂ ਮਾਊਂਟਿੰਗ)।

ਇਸ ਦਾ ਨਤੀਜਾ

ਜਦੋਂ ਅਸੀਂ ਤਿਆਰ ਕੀਤੀ ਸੰਰਚਨਾ ਨੂੰ ਲਾਗੂ ਕਰਦੇ ਹਾਂ ਤਾਂ ਅਸੀਂ ਕੀ ਦੇਖਾਂਗੇ?

ਰਲੇਵੇਂ ਦੀ ਬੇਨਤੀ ਇਸਦੀ ਨਵੀਨਤਮ ਪਾਈਪਲਾਈਨ ਵਿੱਚ ਚੱਲ ਰਹੇ ਟੈਸਟਾਂ ਲਈ ਸੰਖੇਪ ਅੰਕੜੇ ਦਿਖਾਏਗੀ:

ਵੇਰਵਿਆਂ ਲਈ ਹਰੇਕ ਗਲਤੀ ਨੂੰ ਇੱਥੇ ਕਲਿੱਕ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ:

NB: ਧਿਆਨ ਦੇਣ ਵਾਲੇ ਪਾਠਕ ਇਹ ਨੋਟਿਸ ਕਰਨਗੇ ਕਿ ਅਸੀਂ ਇੱਕ NodeJS ਐਪਲੀਕੇਸ਼ਨ ਦੀ ਜਾਂਚ ਕਰ ਰਹੇ ਹਾਂ, ਅਤੇ ਸਕ੍ਰੀਨਸ਼ੌਟਸ ਵਿੱਚ - .NET... ਹੈਰਾਨ ਨਾ ਹੋਵੋ: ਬਸ ਇਹ ਹੈ ਕਿ ਲੇਖ ਨੂੰ ਤਿਆਰ ਕਰਦੇ ਸਮੇਂ, ਪਹਿਲੀ ਐਪਲੀਕੇਸ਼ਨ ਦੀ ਜਾਂਚ ਵਿੱਚ ਕੋਈ ਗਲਤੀ ਨਹੀਂ ਪਾਈ ਗਈ, ਪਰ ਉਹ ਦੂਜੇ ਵਿੱਚ ਪਾਏ ਗਏ ਸਨ।

ਸਿੱਟਾ

ਜਿਵੇਂ ਕਿ ਤੁਸੀਂ ਦੇਖ ਸਕਦੇ ਹੋ, ਕੁਝ ਵੀ ਗੁੰਝਲਦਾਰ ਨਹੀਂ ਹੈ!

ਸਿਧਾਂਤਕ ਤੌਰ 'ਤੇ, ਜੇਕਰ ਤੁਹਾਡੇ ਕੋਲ ਪਹਿਲਾਂ ਹੀ ਸ਼ੈੱਲ ਕੁਲੈਕਟਰ ਹੈ ਅਤੇ ਇਹ ਕੰਮ ਕਰਦਾ ਹੈ, ਪਰ ਤੁਹਾਨੂੰ ਕੁਬਰਨੇਟਸ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ, ਤਾਂ ਇਸ ਨਾਲ ਟੈਸਟਿੰਗ ਨੂੰ ਜੋੜਨਾ ਇੱਥੇ ਦੱਸੇ ਗਏ ਨਾਲੋਂ ਵੀ ਸੌਖਾ ਕੰਮ ਹੋਵੇਗਾ। ਅਤੇ ਵਿੱਚ GitLab CI ਦਸਤਾਵੇਜ਼ ਤੁਹਾਨੂੰ ਰੂਬੀ, ਗੋ, ਗ੍ਰੇਡਲ, ਮਾਵੇਨ ਅਤੇ ਕੁਝ ਹੋਰ ਲਈ ਉਦਾਹਰਣਾਂ ਮਿਲਣਗੀਆਂ।

PS

ਸਾਡੇ ਬਲੌਗ 'ਤੇ ਵੀ ਪੜ੍ਹੋ:

• «ਕੁਬਰਨੇਟਸ ਅਤੇ ਗਿਟਲੈਬ (ਸਮੀਖਿਆ ਅਤੇ ਵੀਡੀਓ ਰਿਪੋਰਟ) ਦੇ ਨਾਲ ਵਧੀਆ CI/CD ਅਭਿਆਸ";
• «GitLab CI ਵਿੱਚ ਕਸਟਮ ਵਰਕਫਲੋ ਬਣਾਉਣ ਲਈ ਸੁਝਾਅ";
• «ਉਤਪਾਦਨ ਵਿੱਚ ਨਿਰੰਤਰ ਏਕੀਕਰਣ ਅਤੇ ਡਿਲੀਵਰੀ ਲਈ GitLab CI".

ਸਰੋਤ: www.habr.com