Sử dụng GitLab CI để chạy thử nghiệm cục bộ?


83

Nếu một dự án GitLab được định cấu hình trên GitLab CI, có cách nào để chạy bản dựng cục bộ không?

Tôi không muốn biến máy tính xách tay của mình thành "người chạy" xây dựng, tôi chỉ muốn tận dụng Docker và .gitlab-ci.ymlchạy thử nghiệm cục bộ (tức là tất cả đều được cấu hình sẵn). Một lợi thế khác của điều đó là tôi chắc chắn rằng tôi đang sử dụng cùng một môi trường cục bộ và trên CI.

Đây là một ví dụ về cách chạy các bản dựng Travis cục bộ bằng Docker , tôi đang tìm kiếm thứ gì đó tương tự với GitLab.


3
nên có sẵn trong devel mới nhất, xem gitlab-ci-đa-Á hậu # 312
jangorecki

Câu trả lời:


93

Kể từ một vài tháng trước, điều này có thể sử dụng gitlab-runner:

gitlab-runner exec docker my-job-name

Lưu ý rằng bạn cần cả dockergitlab-runnercài đặt trên máy tính của mình để làm việc này.

Bạn cũng cần imagekhóa được xác định trong .gitlab-ci.ymltệp của mình . Nếu không sẽ không hoạt động.

Đây là dòng tôi hiện đang sử dụng để thử nghiệm cục bộ bằng cách sử dụng gitlab-runner:

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

Lưu ý: Bạn có thể tránh thêm một --docker-volumesbằng cách cài đặt khóa của mình theo mặc định /etc/gitlab-runner/config.toml. Xem tài liệu chính thức để biết thêm chi tiết . Ngoài ra, sử dụng gitlab-runner exec docker --helpđể xem tất cả các tùy chọn người chạy dựa trên docker (như biến, khối lượng, mạng, v.v.).

Do sự nhầm lẫn trong các nhận xét, tôi dán gitlab-runner --helpkết quả vào đây để bạn có thể thấy rằng gitlab-runner có thể tạo các bản dựng cục bộ:

   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]
   [...]

Như bạn có thể thấy, execlệnh là execute a build locally.

Mặc dù có một vấn đề là không chấp nhận gitlab-runner exechành vi hiện tại , nhưng nó đã được xem xét lại và một phiên bản mới với các tính năng tốt hơn sẽ thay thế chức năng thực thi hiện tại.

Lưu ý rằng quá trình này là sử dụng máy của chính bạn để chạy các bài kiểm tra bằng cách sử dụng bộ chứa docker. Đây không phải là để xác định người chạy tùy chỉnh. Để làm như vậy, chỉ cần vào cài đặt CI / CD của repo và đọc tài liệu ở đó. Nếu bạn muốn đảm bảo người chạy của mình được thực thi thay vì một thẻ từ gitlab.com, hãy thêm một thẻ tùy chỉnh và duy nhất cho người chạy của bạn, đảm bảo nó chỉ chạy các công việc được gắn thẻ và gắn thẻ tất cả các công việc bạn muốn người chạy của mình chịu trách nhiệm.


1
"Nó không bao giờ nên là cách để kiểm tra mọi thứ cục bộ" Tại sao? gitlab-ci.ymlgiống như một vùng chứa Docker được định cấu hình trước. Như tôi đã chỉ ra trong câu hỏi của mình, điều đó có thể xảy ra với Travis và nó hoạt động tốt: github.com/jolicode/JoliCi
Matthieu Napoli,

2
Bạn đang sai anh chàng ... Á hậu gitlab thể được thực hiện tại địa phương, chính xác theo cùng một cách JoliCI không ...
elboletaire

1
Và đó là lệnh tôi đã thêm vào phản hồi. Khi tôi muốn thử gitlab-ci ĐỊA PHƯƠNG, tôi sử dụng lệnh đó. Nó tạo một bộ chứa docker, kéo hình ảnh và chạy các bài kiểm tra cục bộ. Chính xác có bao JoliCI không ...
elboletaire

1
Tôi đã chỉnh sửa phản hồi để bạn có thể thấy rõ cách gitlab-runnersử dụng để chạy các bản dựng cục bộ.
elboletaire

5
gitlab-runner execđang bị phản đối sau khi GitLab 10.0 , bỏ phiếu gitlab.com/gitlab-org/gitlab-runner/issues/2797 để hỗ trợ một sự thay thế trước khi điều này xảy ra
Alfageme

3

Nếu bạn đang chạy Gitlab bằng cách sử dụng hình ảnh Docker có: https://hub.docker.com/r/gitlab/gitlab-ce , nó có thể chạy đường ống bằng cách phơi bày các địa phương docker.sockvới một lựa chọn khối lượng: -v /var/run/docker.sock:/var/run/docker.sock. Thêm tùy chọn này vào vùng chứa Gitlab sẽ cho phép nhân viên của bạn truy cập vào phiên bản docker trên máy chủ.


Tôi hiện đang cố gắng thực thi một tác vụ trong .gitlab-ci.ymltệp trong dự án của mình, trên một Runner được triển khai dưới dạng vùng chứa Docker. Tôi có cần liên kết mount mã src của dự án của mình vào Runner để nó tìm / chạy tác vụ không? Hay điều này bằng cách nào đó có thể xảy ra với những gì bạn đã nói trong câu trả lời của mình, tức là kết nối máy khách từ xa như trong máy Docker 'eval "$ (docker-machine env default)"'?
Greg Brown

2

Tôi hiện đang làm việc để tạo một trình chạy gitlab hoạt động tại địa phương. Vẫn còn trong giai đoạn đầu, nhưng cuối cùng nó sẽ trở nên rất phù hợp. Có vẻ như gitlab không muốn / có thời gian để làm điều này, vì vậy bạn bắt đầu. https://github.com/firecow/gitlab-runner-local


2

Một cách tiếp cận khác là có một công cụ xây dựng cục bộ được cài đặt trên máy tính và máy chủ của bạn cùng một lúc. Vì vậy, về cơ bản, .gitlab-ci.yml của bạn về cơ bản sẽ gọi công cụ xây dựng ưa thích của bạn.

Đây là một ví dụ .gitlab-ci.yml mà tôi sử dụng với 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/

Và trong nuke.build, tôi đã xác định 3 mục tiêu có tên giống như 3 giai đoạn (xây dựng, thử nghiệm, đóng gói)

Bằng cách này, bạn có một thiết lập có thể tái tạo (tất cả những thứ khác được định cấu hình bằng công cụ xây dựng của bạn) và bạn có thể kiểm tra trực tiếp các mục tiêu khác nhau của công cụ xây dựng của mình.

(Tôi có thể gọi. \ build.ps1,. \ build.ps1 test và. \ build.ps1 pack khi tôi muốn)


1

Trình chạy GitLab dường như chưa hoạt động trên Windows và có một vấn đề mở để giải quyết vấn đề này .

Vì vậy, trong thời gian chờ đợi, tôi đang chuyển mã tập lệnh của mình sang một tập lệnh bash, mà tôi có thể dễ dàng ánh xạ tới một vùng chứa docker đang chạy cục bộ và thực thi.

Trong trường hợp này, tôi muốn xây dựng một vùng chứa docker trong công việc của mình, vì vậy tôi tạo một tập lệnh 'build':

#!/bin/bash

docker build --pull -t myimage:myversion .

trong .gitlab-ci.yaml của tôi, tôi thực thi tập lệnh:

image: docker:latest

services:
- docker:dind

before_script:
- apk add bash

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

Để chạy tập lệnh cục bộ bằng powershell, tôi có thể bắt đầu hình ảnh cần thiết và ánh xạ ổ đĩa với các tệp nguồn:

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

cài đặt bash nếu không có:

docker exec $containerId apk add bash

Đặt quyền trên tập lệnh bash:

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

Thực thi tập lệnh:

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

Sau đó dừng vùng chứa:

docker stop $containerId

Và cuối cùng là dọn dẹp thùng chứa:

docker container rm $containerId

Điều này yêu cầu một Dockerfile, mà bạn không đề cập đến.
Cerin

@Cerin cần có dockerfile nào? docker: dind là hình ảnh docker chính thức, tôi không tạo nó.
Glen Thomas

1

Ý tưởng là giữ các lệnh kiểm tra bên ngoài .gitlab-ci.yml. Tôi sử dụng Makefileđể chạy một cái gì đó giống như make checkvà của tôi .gitlab-ci.ymlchạy các makelệnh tương tự mà tôi sử dụng cục bộ để kiểm tra nhiều thứ khác nhau trước khi cam kết.
Bằng cách này, bạn sẽ có một nơi chứa tất cả / hầu hết các lệnh của mình ( Makefile) và .gitlab-ci.ymlsẽ chỉ có những thứ liên quan đến CI.


1

Tôi đang sử dụng Windows bằng VSCode với WSL

Tôi không muốn đăng ký PC làm việc của mình với tư cách là người chạy nên thay vào đó tôi đang chạy cục bộ các giai đoạn yaml của mình để kiểm tra chúng trước khi tải chúng lên

$ 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

những gì về docker? Bạn đã chỉ định 'hình ảnh' trong yaml của mình
Shubham Takode

@ShubhamTakode Ban đầu tôi đã đi theo con đường đó nhưng để mọi thứ hoạt động trơn tru trên WSL chứng tỏ tôi đang nỗ lực nhiều hơn vào vấn đề này.
Jacksonkr
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.