Використовувати GitLab CI для запуску тестів локально?

Якщо проект GitLab налаштовано на GitLab CI, чи є спосіб запустити збірку локально?

Я не хочу перетворювати свій ноутбук на "бігун" збірки, я просто хочу скористатися Docker і .gitlab-ci.ymlзапускати тести локально (тобто все це попередньо налаштовано). Ще однією перевагою цього є те, що я впевнений, що використовую одне і те ж середовище локально та на CI.

Ось приклад того, як запускати збірки Travis локально за допомогою Docker , я шукаю щось подібне з GitLab.

Кілька місяців тому це можливо за допомогою gitlab-runner:

gitlab-runner exec docker my-job-name

Зверніть увагу, що вам потрібні як докер, так і 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 може робити збірки локально:

   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поведінки , її переглянули, і нова версія з розширеними функціями замінить поточну функціональність exec.

Зверніть увагу, що цей процес полягає у використанні власної машини для запуску тестів за допомогою контейнерів докерів. Це не для визначення власних бігунів. Для цього просто перейдіть до налаштувань CI / CD вашого репо та прочитайте там документацію. Якщо ви хочете, щоб ваш бігун був запущений замість того, щоб виконати його з gitlab.com, додайте власний та унікальний тег до вашого бігуна, переконайтеся, що він виконує лише позначені завдання та позначте всі завдання, за які ви хочете, щоб ваш бігун відповідав.

Якщо ви працюєте Gitlab з допомогою докер зображення є: https://hub.docker.com/r/gitlab/gitlab-ce , можна запускати трубопроводи, піддаючи місцевий docker.sockз опцією гучності: -v /var/run/docker.sock:/var/run/docker.sock. Додавання цієї опції до контейнера Gitlab дозволить вашим працівникам отримати доступ до екземпляра докера на хості.

Зараз я працюю над створенням бігуна gitlab, який працює локально. Ще на ранніх етапах, але з часом це стане дуже актуальним. Здається, gitlab не хоче / не встигає це зробити, от і ось. https://github.com/firecow/gitlab-runner-local

Інший підхід - мати локальний інструмент збірки, який одночасно встановлюється на вашому ПК та сервері. Отже, ваш .gitlab-ci.yml в основному буде викликати ваш улюблений інструмент побудови.

Ось приклад .gitlab-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 test і. \ build.ps1 pack, коли захочу)

Виявляється, що бігун GitLab ще не працює у Windows, і вирішено це питання .

Отже, тим часом я переношу свій код сценарію в скрипт bash, який я легко можу зіставити з контейнером докера, що працює локально, і виконати.

У цьому випадку я хочу створити контейнер докера у своєму завданні, тому створюю сценарій 'build':

#!/bin/bash

docker build --pull -t myimage:myversion .

у своєму .gitlab-ci.yaml я виконую сценарій:

image: docker:latest

services:
- docker:dind

before_script:
- apk add bash

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

Для локального запуску сценарію за допомогою PowerShell я можу запустити потрібне зображення та зіставити том з вихідними файлами:

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

встановити bash, якщо його немає:

docker exec $containerId apk add bash

Встановіть дозволи для сценарію 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

Ідея полягає в тому, щоб тримати команди перевірки поза .gitlab-ci.yml. Я використовую Makefileдля запуску щось на зразок, make checkі я .gitlab-ci.ymlзапускаю ті самі makeкоманди, що і локально, щоб перевіряти різні речі перед комітом.
Таким чином у вас буде одне місце з усіма / більшістю ваших команд ( Makefile), і ви .gitlab-ci.ymlбудете мати лише матеріали, пов’язані з CI.

Я працюю в Windows, використовуючи VSCode з WSL

Я не хотів реєструвати свій робочий ПК як запуску, тому замість цього я запускаю свої етапи yaml локально, щоб перевірити їх, перш ніж завантажувати

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

ямл

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