स्थानीय स्तर पर परीक्षण चलाने के लिए GitLab CI का उपयोग करें?

Question 1

यदि GitLab CI को GitLab CI पर कॉन्फ़िगर किया गया है, तो क्या बिल्ड को स्थानीय स्तर पर चलाने का कोई तरीका है?

मैं अपने लैपटॉप को बिल्ड "रनर" में बदलना नहीं चाहता, मैं सिर्फ डॉकटर का लाभ लेना चाहता हूं और .gitlab-ci.ymlस्थानीय स्तर पर परीक्षण चलाना चाहता हूं (यानी यह सभी पूर्व-कॉन्फ़िगर है)। इसका एक और फायदा यह है कि मुझे यकीन है कि मैं उसी वातावरण का स्थानीय स्तर पर और सीआई पर उपयोग कर रहा हूं।

ट्रैविस को कैसे चलाया जाए इसका एक उदाहरण यहां दिया गया है कि डॉकर का उपयोग करके स्थानीय रूप से निर्माण किया जाता है , मैं GitLab के साथ कुछ इसी तरह की तलाश कर रहा हूं।

Question 2

कुछ महीने पहले से यह संभव है gitlab-runner:

gitlab-runner exec docker my-job-name

ध्यान दें कि इस कार्य को करने के लिए आपको अपने कंप्यूटर पर docker और install दोनों की आवश्यकता है gitlab-runner।

आपको imageअपनी .gitlab-ci.ymlफ़ाइल में परिभाषित कुंजी की भी आवश्यकता है । अन्यथा काम नहीं करेगा।

वर्तमान में मैं स्थानीय रूप से उपयोग करने के लिए परीक्षण के लिए उपयोग की जाने वाली रेखा यहां हूं gitlab-runner:

gitlab-runner exec docker test --docker-volumes "/home/elboletaire/.ssh/id_rsa:/root/.ssh/id_rsa:ro"

नोट: आप एक जोड़ने से बच सकते हैं--docker-volumes अपनी कुंजी सेटिंग के साथ डिफ़ॉल्ट रूप/etc/gitlab-runner/config.toml । अधिक विवरण के लिए आधिकारिक दस्तावेज देखें । इसके अलावा, gitlab-runner exec docker --helpसभी डॉकटर-आधारित रनर विकल्प (जैसे चर, वॉल्यूम, नेटवर्क, आदि) देखने के लिए उपयोग करें।

टिप्पणियों में भ्रम के कारण, मैं यहां gitlab-runner --helpपरिणाम पेस्ट करता हूं , इसलिए आप देख सकते हैं कि गिटलैब-धावक स्थानीय स्तर पर बना सकते हैं:

   gitlab-runner --help
NAME:
   gitlab-runner - a GitLab Runner

USAGE:
   gitlab-runner [global options] command [command options] [arguments...]
   
VERSION:
   1.1.0~beta.135.g24365ee (24365ee)
   
AUTHOR(S):
   Kamil Trzciński <ayufan@ayufan.eu> 
   
COMMANDS:
   exec         execute a build locally
   [...]
   
GLOBAL OPTIONS:
   --debug          debug mode [$DEBUG]
   [...]

जैसा कि आप देख सकते हैं, execकमांड को है execute a build locally।

हालांकि वर्तमान gitlab-runner execव्यवहार को कम करने के लिए एक मुद्दा था , यह फिर भी इस पर पुनर्विचार किया जा रहा है और अधिक से अधिक सुविधाओं वाला एक नया संस्करण वर्तमान निष्पादन कार्यक्षमता को बदल देगा।

ध्यान दें कि यह प्रक्रिया डॉकटर कंटेनरों का उपयोग करके परीक्षण चलाने के लिए अपनी मशीन का उपयोग करना है। यह कस्टम धावकों को परिभाषित नहीं करना है। ऐसा करने के लिए, बस अपने रेपो की सीआई / सीडी सेटिंग्स पर जाएं और वहां प्रलेखन पढ़ें। यदि आप यह सुनिश्चित करना चाहते हैं कि आपके धावक को gitlab.com से एक के बजाय निष्पादित किया गया है, तो अपने धावक के लिए एक कस्टम और अद्वितीय टैग जोड़ें, यह सुनिश्चित करें कि यह केवल टैग की गई नौकरियां चलाता है और उन सभी नौकरियों को टैग करता है जो आप चाहते हैं कि आपका धावक ज़िम्मेदार हो।

Question 3

यदि आप वहां docker की इमेज का उपयोग करके Gitlab चला रहे हैं: https://hub.docker.com/r/gitlab/gitlab-ce , तो docker.sockवॉल्यूम विकल्प के साथ स्थानीय को उजागर करके पाइपलाइन चलाना संभव है -v /var/run/docker.sock:/var/run/docker.sock:। Gitlab कंटेनर में इस विकल्प को जोड़ने से आपके कार्यकर्ता होस्ट पर docker के उदाहरण तक पहुंच सकेंगे।

Question 4

मैं वर्तमान में gitlab धावक बनाने पर काम कर रहा हूं जो स्थानीय स्तर पर काम करता है। अभी भी शुरुआती चरणों में है, लेकिन अंततः यह बहुत प्रासंगिक हो जाएगा। ऐसा नहीं लगता कि गिटलैब चाहते हैं / इसे बनाने का समय है, इसलिए यहां आप जाएं। https://github.com/firecow/gitlab-runner-local

Question 5

एक अन्य दृष्टिकोण एक स्थानीय बिल्ड टूल है जो आपके पीसी और आपके सर्वर पर एक ही समय में स्थापित होता है। तो मूल रूप से, आपका .itlab-ci.yml मूल रूप से आपके पसंदीदा बिल्ड टूल को कॉल करेगा।

यहाँ एक उदाहरण .ITlab-ci.yml है जिसे मैं nuke.build के साथ उपयोग करता हूं:

stages:
    - build
    - test
    - pack

variables:
    TERM: "xterm" # Use Unix ASCII color codes on Nuke

before_script:
    - CHCP 65001  # Set correct code page to avoid charset issues

.job_template: &job_definition
  except:
    - tags

build:
    <<: *job_definition
    stage: build
    script:
        - "./build.ps1"

test:
    <<: *job_definition
    stage: test
    script:
        - "./build.ps1 test"
    variables:
        GIT_CHECKOUT: "false"

pack:
    <<: *job_definition
    stage: pack
    script:
        - "./build.ps1 pack"
    variables:
        GIT_CHECKOUT: "false"
    only:
        - master
    artifacts:
        paths:
            - output/

और nuke.build में मैंने 3 चरणों की तरह नामित 3 लक्ष्यों को परिभाषित किया है (निर्माण, परीक्षण, पैक)

इस तरह आपके पास एक प्रतिलिपि प्रस्तुत करने योग्य सेटअप है (अन्य सभी चीजें आपके बिल्ड टूल के साथ कॉन्फ़िगर की गई हैं) और आप सीधे अपने बिल्ड टूल के विभिन्न लक्ष्यों का परीक्षण कर सकते हैं।

(मैं कॉल कर सकता हूँ। \ build.ps1,। \ build.ps1 परीक्षण और। \ build.ps1 पैक जब मैं चाहता हूँ)

Question 6

GitLab धावक अभी तक विंडोज पर काम नहीं करता है और इसे हल करने के लिए एक खुला मुद्दा है ।

तो, इस बीच मैं अपने स्क्रिप्ट कोड को बैश स्क्रिप्ट पर स्थानांतरित कर रहा हूं, जिसे मैं आसानी से डॉकटर कंटेनर में मैप कर सकता हूं स्थानीय रूप से चलने वाले और निष्पादित ।

इस मामले में मैं अपनी नौकरी में एक डॉकटर कंटेनर बनाना चाहता हूं, इसलिए मैं एक स्क्रिप्ट 'बिल्ड' बनाता हूं:

#!/bin/bash

docker build --pull -t myimage:myversion .

मेरे .itlab-ci.yaml में मैं स्क्रिप्ट निष्पादित करता हूं:

image: docker:latest

services:
- docker:dind

before_script:
- apk add bash

build:
stage: build
script:
- chmod 755 build
- build

स्थानीय रूप से पॉवरशेल का उपयोग करके स्क्रिप्ट चलाने के लिए मैं आवश्यक छवि शुरू कर सकता हूं और स्रोत फ़ाइलों के साथ वॉल्यूम को मैप कर सकता हूं:

$containerId = docker run --privileged -d -v ${PWD}:/src docker:dind

मौजूद न होने पर बैश स्थापित करें:

docker exec $containerId apk add bash

बैश स्क्रिप्ट पर अनुमतियाँ सेट करें:

docker exec -it $containerId chmod 755 /src/build

स्क्रिप्ट निष्पादित करें:

docker exec -it --workdir /src $containerId bash -c 'build'

फिर कंटेनर बंद करें:

docker stop $containerId

और अंत में कंटेनर को साफ करें:

docker container rm $containerId

Question 7

विचार यह है कि चेक कमांड को बाहर रखा जाए .gitlab-ci.yml। मैं Makefileकिसी चीज़ को चलाने के लिए उपयोग करता make checkहूं और मेरी .gitlab-ci.ymlवही makeआज्ञाएं चलती हैं जिनका मैं स्थानीय रूप से उपयोग करता हूं।
इस तरह आपके सभी / अधिकांश कमांडों के साथ एक जगह होगी ( Makefile) और .gitlab-ci.ymlकेवल CI से संबंधित सामान होगा।

Question 8

मैं विंडोज पर WSL के साथ VSCode का उपयोग कर रहा हूं

मैं अपने काम के पीसी को एक धावक के रूप में पंजीकृत नहीं करना चाहता था, इसलिए इसके बजाय मैं अपने yaml चरणों को स्थानीय स्तर पर चला रहा हूं ताकि मैं उन्हें अपलोड करने से पहले उनका परीक्षण कर सकूं

$ sudo apt-get install gitlab-runner
$ gitlab-runner exec shell build

YAML

image: node:10.19.0 # https://hub.docker.com/_/node/
# image: node:latest

cache:
  # untracked: true
  key: project-name
  # key: ${CI_COMMIT_REF_SLUG} # per branch
  # key:
  #   files:
  #     - package-lock.json # only update cache when this file changes (not working) @jkr
  paths:
    - .npm/
    - node_modules
    - build

stages:
  - prepare # prepares builds, makes build needed for testing
  - test # uses test:build specifically @jkr
  - build
  - deploy

# before_install:

before_script:
  - npm ci --cache .npm --prefer-offline

prepare:
  stage: prepare
  needs: []
  script:
    - npm install

test:
  stage: test
  needs: [prepare]
  except:
    - schedules
  tags:
    - linux
  script:
    - npm run build:dev
    - npm run test:cicd-deps
    - npm run test:cicd # runs puppeteer tests @jkr
  artifacts:
    reports:
      junit: junit.xml
    paths:
      - coverage/

build-staging:
  stage: build
  needs: [prepare]
  only:
    - schedules
  before_script:
    - apt-get update && apt-get install -y zip
  script:
    - npm run build:stage
    - zip -r build.zip build
  # cache:
  #   paths:
  #     - build
  #   <<: *global_cache
  #   policy: push
  artifacts:
    paths:
      - build.zip

deploy-dev:
  stage: deploy
  needs: [build-staging]
  tags: [linux]
  only:
    - schedules
  #   # - branches@gitlab-org/gitlab
  before_script:
    - apt-get update && apt-get install -y lftp
  script:
    # temporarily using 'verify-certificate no'
    # for more on verify-certificate @jkr: https://www.versatilewebsolutions.com/blog/2014/04/lftp-ftps-and-certificate-verification.html
    # variables do not work with 'single quotes' unless they are "'surrounded by doubles'"
    - lftp -e "set ssl:verify-certificate no; open mediajackagency.com; user $LFTP_USERNAME $LFTP_PASSWORD; mirror --reverse --verbose build/ /var/www/domains/dev/clients/client/project/build/; bye"
  # environment:
  #   name: staging
  #   url: http://dev.mediajackagency.com/clients/client/build
  #   # url: https://stg2.client.co
  when: manual
  allow_failure: true

build-production:
  stage: build
  needs: [prepare]
  only:
    - schedules
  before_script:
    - apt-get update && apt-get install -y zip
  script:
    - npm run build
    - zip -r build.zip build
  # cache:
  #   paths:
  #     - build
  #   <<: *global_cache
  #   policy: push
  artifacts:
    paths:
      - build.zip

deploy-client:
  stage: deploy
  needs: [build-production]
  tags: [linux]
  only:
    - schedules
    # - master
  before_script:
    - apt-get update && apt-get install -y lftp
  script:
    - sh deploy-prod
  environment:
    name: production
    url: http://www.client.co
  when: manual
  allow_failure: true