CI:GitLab-CI 和 Gitlab-Runner 安装使用

本文详细介绍了如何配置和使用GitLab-CI与GitLab-Runner进行持续集成。从系统环境设置、项目配置到GitLab-Runner的安装、注册和启动,每个步骤都有清晰的说明。此外,还探讨了.gitlab-ci.yml文件的作用以及各种Executor的适用场景,帮助读者选择最适合的构建方式。
摘要由CSDN通过智能技术生成

从GitLab 8.0版开始,GitLab-CI持续集成服务完整整合到GitLab中,并在所有项目中默认启用。

配置项目Gitlab-Runner,并在项目的根目录中添加.gitlab-ci.yml文件,就能在每次提交或推送时触发CI pipeline,实现持续集成。

系统环境
  • 客户端环境:OSX 10.13.6,Git
  • 服务端环境:Linux/Unix,GitLab 8.9.3,node v9.8.0,npm 5.4.0
项目设置

features 中 builds 要勾选(通常默认是勾选的)。

安装 GitLab-Runner
sudo curl --output /usr/local/bin/gitlab-runner https://gitlab-runner-downloads.s3.amazonaws.com/latest/binaries/gitlab-runner-darwin-amd64
设置执行权限
sudo chmod +x /usr/local/bin/gitlab-runner
注册 GitLab-Runner
gitlab-runner register

接下来需要输入 CI URL 和 token,可以从项目仓库的 GitLab 页面中的 Runners 下获取。

如果注册时出现类似下列错误:
ERROR: Registering runner… failed runner=< token > status=405 Method Not Allowed
PANIC: Failed to register this runner. Perhaps you are having network problems
则需要检查当前使用的 GitLab 版本,如过使用的是8.x版本的GitLab,则只能使用1.x 版本的 GitLab-Runner。以mac为例,需要重新安装:

sudo curl --output /usr/local/bin/gitlab-runner https://gitlab-ci-multi-runner-downloads.s3.amazonaws.com/v1.11.1/binaries/gitlab-ci-multi-runner-darwin-amd64
sudo chmod +x /usr/local/bin/gitlab-runner

在选择 Run untagged 设置时,建议填写 true (默认为 false),否则在测试或者开发环境提交时会有很多问题。

在输入Runner executor时,如果使用本地 runner 则填shell,然后在项目根目下创建.gitlab-ci.yml文件。

启动 GitLab-Runner
cd ~
gitlab-runner install
gitlab-runner start
gitlab-runner restart
gitlab-runner status
gitlab-runner stop
gitlab-runner uninstall
gitlab-runner --help
.gitlab-ci.yml

GitLab-Runner 按照 .gitlab-ci.yml 文件的描述来进行项目管理工作。默认情况下stages包含三个名称 :build、test、deploy。

.gitlab-ci.yml 文件用来定义一个在指定时间(提交和拉取)运行的工作集,可以配置任意数量任意顶级键名名称和至少定义了script的工作。script中可以直接书写 shell 命令或执行指定 shell 文件。

下面是一个可能的.gitlab-ci.yml文件内容:

stages:
  - build
  - test
  - deploy
echotest:
    stage: test
    tags: test
    script: "node -v && npm -v"
checkversion:
    stage: test
    tags: test
    script: "source ./checkversion.sh"
syncpackage:
    stage: test
    tags: test
    script: "source ./syncpackage.sh"
Runner executor #todo 翻译

GitLab Runner implements a number of executors that can be used to run your builds in different scenarios. If you are not sure what to select, read the I am not sure section. Visit the compatibility chart to find out what features each executor does and does not support.

To jump into the specific documentation for each executor, visit:

  • SSH
  • Shell
  • Parallels
  • VirtualBox
  • Docker
  • Docker Machine (auto-scaling)
  • Kubernetes

Selecting the executor
The executors support different platforms and methodologies for building a project. The table below shows the key facts for each executor which will help you decide which executor to use.

Shell Executor
Shell is the simplest executor to configure. All required dependencies for your builds need to be installed manually on the same machine that the Runner is installed on.

Virtual Machine Executor (VirtualBox / Parallels)
This type of executor allows you to use an already created virtual machine, which is cloned and used to run your build. We offer two full system virtualization options: VirtualBox and Parallels. They can prove useful if you want to run your builds on different operating systems, since it allows the creation of virtual machines on Windows, Linux, OSX or FreeBSD, then GitLab Runner connects to the virtual machine and runs the build on it. Its usage can also be useful for reducing infrastructure costs.

Docker Executor
A great option is to use Docker as it allows a clean build environment, with easy dependency management (all dependencies for building the project can be put in the Docker image). The Docker executor allows you to easily create a build environment with dependent services, like MySQL.

Docker Machine
The Docker Machine is a special version of the Docker executor with support for auto-scaling. It works like the normal Docker executor but with build hosts created on demand by Docker Machine.

Kubernetes Executor
The Kubernetes executor allows you to use an existing Kubernetes cluster for your builds. The executor will call the Kubernetes cluster API and create a new Pod (with a build container and services containers) for each GitLab CI job.

SSH Executor
The SSH executor is added for completeness, but it’s the least supported among all executors. It makes GitLab Runner connect to an external server and runs the builds there. We have some success stories from organizations using this executor, but usually we recommend using one of the other types.

Compatibility chart
Supported features by different executors:
在这里插入图片描述
Supported systems by different shells:

Shells BashWindows BatchPowerShell
Windows✓ (default)
Linux✓ (default)
OSX✓ (default)
FreeBSD✓ (default)

Supported systems for interactive web terminals by different shells:

ShellsBashWindows BatchPowerShell
Windows
Linux
OSX
FreeBSD
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值