GitLab 프로젝트가 GitLab CI에 구성된 경우 로컬에서 빌드를 실행할 수있는 방법이 있습니까?
랩톱을 빌드 “러너”로 바꾸고 싶지 않고 Docker를 활용하고 .gitlab-ci.yml
로컬에서 테스트를 실행 하고 싶습니다 (즉, 모두 미리 구성되어 있음). 또 다른 장점은 로컬 및 CI에서 동일한 환경을 사용하고 있다는 것입니다.
다음은 Docker를 사용하여 로컬에서 Travis 빌드를 실행하는 방법 의 예입니다 . 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
행동을 ,이 재고되고 결국 더 큰 기능을 가진 새로운 버전은 현재 간부 인 기능을 대체합니다.
이 프로세스는 자체 머신을 사용하여 도커 컨테이너를 사용하여 테스트를 실행하는 것입니다. 이것은 커스텀 러너를 정의하는 것이 아닙니다 . 이렇게하려면 리포지토리의 CI / CD 설정으로 이동하여 설명서를 읽으십시오. 러너가 gitlab.com에서 실행되는 대신 실행되도록하려면 러너에 사용자 지정 및 고유 태그를 추가하고 태그가 지정된 작업 만 실행하고 러너가 담당 할 모든 작업에 태그를 지정해야합니다.
답변
Docker 이미지를 사용하여 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
답변
또 다른 방법은 PC와 서버에 동시에 설치되는 로컬 빌드 도구를 사용하는 것입니다. 따라서 기본적으로 .gitlab-ci.yml은 기본적으로 선호하는 빌드 도구를 호출합니다.
다음은 nuke.build와 함께 사용하는 .gitlab-ci.yml 예제입니다.
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 팩을 호출 할 수 있습니다)
답변
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 관련 항목 만 있습니다.
답변
WSL 과 함께 VSCode 를 사용하는 Windows에 있습니다.
내 업무용 PC를 러너로 등록하고 싶지 않았기 때문에 대신 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
