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

Question

如果在GitLab CI上配置了GitLab项目，有没有办法在本地运行构建？

我不想把我的笔记本电脑变成一个版本＆＃34;跑步者＆＃34;，我只想利用Docker和.gitlab-ci.yml在本地运行测试（即它＆＃39;所有预先配置的）。这样做的另一个好处是，我确信我在本地和CI上使用相同的环境。

以下是how to run Travis builds locally using Docker的示例，我正在寻找与GitLab类似的内容。

Answer 1

几个月前，可以使用 @interface ViewController ()<NSURLConnectionDataDelegate> //Put these in custom cell file @property (weak, nonatomic) IBOutlet UIProgressView *progressView; @property (weak, nonatomic) IBOutlet UIImageView *imageView; @property (strong, nonatomic) NSURLConnection *connectionManager; @property (strong, nonatomic) NSMutableData *downloadedMutableData; @property (strong, nonatomic) NSURLResponse *urlResponse; @end @implementation ViewController - (void)viewDidLoad { [super viewDidLoad]; //Start download request logic self.downloadedMutableData = [[NSMutableData alloc] init]; NSURLRequest *urlRequest = [NSURLRequest requestWithURL:[NSURL URLWithString:@"https://www.planwallpaper.com/static/images/63906_1_BdhSun5.jpg"] cachePolicy:NSURLRequestReloadIgnoringLocalCacheData timeoutInterval:60.0]; self.connectionManager = [[NSURLConnection alloc] initWithRequest:urlRequest delegate:self]; } #pragma mark - Delegate Methods -(void)connection:(NSURLConnection *)connection didReceiveResponse:(NSURLResponse *)response { NSLog(@"%lld", response.expectedContentLength); self.urlResponse = response; } //Show progress download while receiving data -(void)connection:(NSURLConnection *)connection didReceiveData:(NSData *)data { [self.downloadedMutableData appendData:data]; self.progressView.progress = ((100.0/self.urlResponse.expectedContentLength)*self.downloadedMutableData.length)/100; if (self.progressView.progress == 1) { self.progressView.hidden = YES; } else { self.progressView.hidden = NO; } NSLog(@"%.0f%%", ((100.0/self.urlResponse.expectedContentLength)*self.downloadedMutableData.length)); } -(void)connectionDidFinishLoading:(NSURLConnection *)connection { NSLog(@"Finished"); self.imageView.image = [UIImage imageWithData:self.downloadedMutableData]; } ：

gitlab-runner

请注意，您需要在计算机上安装docker和gitlab-runner才能使其正常运行。

您还需要gitlab-runner exec docker my-job-name 文件中定义的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。 See the official documentation for more details

由于评论中的混淆，我在此处粘贴了/etc/gitlab-runner/config.toml结果，因此您可以看到gitlab-runner可以在本地进行构建：

gitlab-runner --help

如您所见， 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 list List all configured runners run run multi runner service register register a new runner install install service uninstall uninstall service start start service stop stop service restart restart service status get status of a service run-single start single runner unregister unregister specific runner verify verify all registered runners artifacts-downloader download and extract build artifacts (internal) artifacts-uploader create and upload build artifacts (internal) cache-archiver create and upload cache artifacts (internal) cache-extractor download and extract cache artifacts (internal) help, h Shows a list of commands or help for one command GLOBAL OPTIONS: --debug debug mode [$DEBUG] --log-level, -l "info" Log level (options: debug, info, warn, error, fatal, panic) --cpuprofile write cpu profile to file [$CPU_PROFILE] --help, -h show help --version, -v print the version 命令是exec。

  

请注意，此过程是使用您自己的计算机使用docker容器运行测试。 不来定义自定义运行器。为此，只需转到您的repo的CI / CD设置并阅读其中的文档。如果你想确保你的跑步者被执行而不是gitlab.com的跑步者，你可以为你的跑步者添加一个自定义和唯一的标签，确保它只运行被标记的工作并标记你希望你的跑步者负责的所有工作。

Answer 2

我使用这种基于 docker 的方法。

0。创建一个 git repo 来测试这个答案

mkdir my-git-project
cd my-git-project
git init
git commit --allow-empty -m"Initialize repo to showcase gitlab-runner locally."

1.转到您的 git 目录

cd my-git-project

2.创建一个 .gitlab-ci.yml

示例.gitlab-ci.yml

image: alpine

test:
  script:
    - echo "Hello Gitlab-Runner"

3.创建一个安装了项目目录的 docker 容器

docker run -d \
  --name gitlab-runner \
  --restart always \
  -v $PWD:$PWD \
  -v /var/run/docker.sock:/var/run/docker.sock \
  gitlab/gitlab-runner:latest

(-d) 在后台运行容器并打印容器 ID

(--restart 总是) or not?

(-v $PWD:$PWD) 挂载当前目录到容器当前目录

(-v /var/run/docker.sock:/var/run/docker.sock) 这使容器可以访问主机的 docker 套接字，以便它可以启动“兄弟容器”（例如 Alpine）。< /p>

(gitlab/gitlab-runner:latest) 来自 dockerhub 的最新可用镜像。

4.执行

docker exec -it -w $PWD gitlab-runner gitlab-runner exec docker test
#                           ^           ^            ^     ^      ^
#                           |           |            |     |      |
#                          (a)         (b)          (c)   (d)    (e)

(a) docker 容器名称

(b) 在docker容器内执行命令"gitlab-runner"

(c)(d)(e) 使用“docker executer”运行 gitlab-runner 并运行名为“test”的作业

5.打印

...
Executing "step_script" stage of the job script
$ echo "Hello Gitlab-Runner"
Hello Gitlab-Runner
Job succeeded
...

注意： runner 只会在代码库的 commited 状态下工作。未提交的更改将被忽略。 例外：.gitlab-ci.yml 本身没有被承诺考虑在内。

Answer 3

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

Answer 4

我目前正在制作一个可以在本地工作的gitlab运行程序。 仍处于早期阶段，但最终它将变得非常重要。 gitlab似乎不想要/没有时间做这个，所以就到这里。 https://github.com/firecow/gitlab-runner-local

Answer 5

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

Answer 6

The GitLab runner appears to not work on Windows yet and there is an open issue to resolve this.

So, in the meantime I am moving my script code out to a bash script, which I can easily map to a docker container running locally and execute.

In this case I want to build a docker container in my job, so I create a script 'build':

#!/bin/bash

docker build --pull -t myimage:myversion .

in my .gitlab-ci.yaml I execute the script:

image: docker:latest

services:
- docker:dind

before_script:
- apk add bash

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

To run the script locally using powershell I can start the required image and map the volume with the source files:

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

install bash if not present:

docker exec $containerId apk add bash

Set permissions on the bash script:

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

Execute the script:

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

Then stop the container:

docker stop $containerId

And finally clean up the container:

docker container rm $containerId

Answer 7

我在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

Answer 8

想法是将检查命令保留在@Override public void onRequestPermissionResult(int RequestCode, String[] permissions, int[] grantResults) { super.onRequestPermissionResult(RequestCode, permissions, grantResults); CalendarEventsPackage.onRequestPermissionResult(RequestCode, permissions, grantResults); } 之外。我使用.gitlab-ci.yml运行类似Makefile的程序，而我的make check运行相同的.gitlab-ci.yml命令，这些命令在本地用于提交之前检查各种事情。
这样，您将在所有/大部分命令（make）中占据一席之地，而Makefile将仅包含与CI相关的内容。

Answer 9

我编写了一个工具来在本地运行所有 GitLab-CI 作业，而无需提交或推送，只需使用命令 ci-toolbox my_job_name。

项目网址：https://gitlab.com/mbedsys/citbx4gitlab

Answer 10

多年前，我使用 Makefile 和 docker-compose 构建了这个简单的解决方案来在 docker 中运行 gitlab runner，您也可以使用它在本地执行作业，并且应该可以在 docker 工作的所有系统上运行：

https://gitlab.com/1oglop1/gitlab-runner-docker

docker-compose.override.yaml

中几乎没有要更改的内容

version: "3"
services:
    runner:
      working_dir: <your project dir>
      environment:
        - REGISTRATION_TOKEN=<token if you want to register>
      volumes:
        - "<your project dir>:<your project dir>"

然后在您的项目中，您可以按照其他答案中提到的相同方式执行它：

docker exec -it -w $PWD runner gitlab-runner exec <commands>..