Если проект 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"
Из-за путаницы в комментариях я вставляю сюда
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.источник
gitlab-ci.yml
похож на предварительно настроенный контейнер Docker. Как я указал в своем вопросе, это возможно с Трэвисом, и это хорошо работает: github.com/jolicode/JoliCigitlab-runner
его можно использовать для локального запуска сборок.gitlab-runner exec
является устаревшим после GitLab 10.0 , голосуйте gitlab.com/gitlab-org/gitlab-runner/issues/2797 поддержать замену прежде чем это произойдетЕсли вы работаете Gitlab с помощью докер изображения есть: https://hub.docker.com/r/gitlab/gitlab-ce , можно запускать трубопроводы, подвергая местный
docker.sock
с опцией громкости:-v /var/run/docker.sock:/var/run/docker.sock
. Добавление этой опции в контейнер Gitlab позволит вашим работникам получить доступ к экземпляру докера на хосте.источник
.gitlab-ci.yml
файле в моем проекте на Runner, развернутом как контейнер Docker. Нужно ли мне привязать монтирование кода src моего проекта к Runner, чтобы он мог найти / запустить задачу? Или это каким-то образом возможно с тем, что вы сказали в своем ответе, то есть подключением к удаленному клиенту, как в Docker-машине 'eval "$ (docker-machine env default)"'?В настоящее время я работаю над созданием бегуна 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
источник