使用GitLab CI在本地运行测试？

83

如果在GitLab CI上配置了GitLab项目，是否可以在本地运行构建？

我不想将笔记本电脑变成构建“运行器”，我只是想利用Docker并.gitlab-ci.yml在本地运行测试（即，它们都是预先配置的）。这样做的另一个优点是，我确定我在本地和CI上都使用相同的环境。

这是一个如何使用Docker在本地运行Travis构建的示例，我正在寻找与GitLab类似的东西。

gitlab-ci 
— 马修·那不勒斯
source
3
应该在最新开发版本中可用，请参阅gitlab-ci-multi-runner＃312
— jangorecki 2015年

Answers:

93

从几个月前开始，可以使用gitlab-runner：

gitlab-runner exec docker my-job-name

请注意，您需要在计算机上同时安装docker和dockergitlab-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用于查看所有基于docker的运行器选项（如变量，卷，网络等）。

由于注释中的混乱，我将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功能。

请注意，此过程是使用您自己的机器使用docker容器运行测试。这不是要定义自定义运行器。为此，只需转到您的存储库的CI / CD设置并阅读那里的文档。如果您想确保执行者而不是gitlab.com上的执行者，请向您的执行者添加一个自定义且唯一的标签，确保它仅运行带标签的作业，并标记您希望由该执行者负责的所有作业。

— Elboletaire
source
1
“从来都不应该是在本地测试事物的方法”为什么？gitlab-ci.yml就像一个预先配置的Docker容器。正如我在问题中指出的那样，特拉维斯（Travis）可能存在并且运行良好：github.com/jolicode/JoliCi
— Matthieu Napoli
2
你是错的家伙... gitlab运行程序可以在本地执行，与JoliCI完全一样...
— elboletaire 2016年
1
这就是我添加到响应中的命令。当我想本地尝试gitlab-ci时，我使用了该命令。它创建一个docker容器，拉取映像并在本地运行测试。JoliCI到底是怎么做的……
— elboletaire 2016年
1
我已经编辑了响应，因此您可以清楚地看到如何gitlab-runner用于本地运行构建。
— elboletaire 2016年
5
— Alfageme
3

如果您使用以下docker镜像运行Gitlab：https ://hub.docker.com/r/gitlab/gitlab-ce ，则可以通过docker.sock使用volume选项公开本地来运行管道-v /var/run/docker.sock:/var/run/docker.sock。将此选项添加到Gitlab容器将允许您的工作人员访问主机上的docker实例。

— 皮尔科
source
我目前正在尝试在.gitlab-ci.yml部署为Docker容器的Runner上的项目文件中执行任务。我是否需要将项目的src代码绑定安装到Runner中，以便它查找/运行任务？或者，您在回答中说的话，是否可以通过某种方式实现，例如，将其连接到远程客户端，如在Docker计算机'eval“ $（docker（-machine-env default））”中？
— 格雷格·布朗
2

另一种方法是在计算机和服务器上同时安装本地构建工具。因此，基本上，您的.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包）

— 弗鲁吉耶罗
source
1

GitLab运行程序似乎无法在Windows上运行，并且存在一个开放的问题可以解决此问题。

因此，与此同时，我将脚本代码移至bash脚本，可以轻松地将其映射到本地运行的docker容器并执行。

在这种情况下，我想在我的工作中构建一个docker容器，所以我创建了一个脚本“ 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
— 格伦·托马斯
source
这需要一个Dockerfile，您没有提到。
— 塞林
@Cerin需要什么dockerfile？docker：dind是官方的docker镜像，我没有创建。
— Glen Thomas
1

想法是将检查命令保留在之外.gitlab-ci.yml。我Makefile过去经常运行类似的命令，make check并且.gitlab-ci.yml运行与make本地使用相同的命令来提交之前检查各种内容的命令。
这样，您将在所有/大部分命令（Makefile）中占有一席之地，并且.gitlab-ci.yml仅包含与CI相关的内容。

— Onlyjob
source
1

我在Windows上使用VSCode和WSL

我不想将我的工作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
— 杰克逊克尔
source
码头工人呢？您已在
— Yaml中
@ShubhamTakode我最初走那条路，但是让所有事情在WSL上顺利运行证明我想付出更多的努力。
— Jacksonkr
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.