Использовать 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