CI：GitLab-CI Gitlab-Runner 安装使用
从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 Bash | Windows Batch | PowerShell |
|---|---|---|
| Windows | ✓ | ✓ (default) |
| Linux | ✓ (default) | ✗ |
| OSX | ✓ (default) | ✗ |
| FreeBSD | ✓ (default) | ✗ |
Supported systems for interactive web terminals by different shells:
| Shells | Bash | Windows Batch | PowerShell |
|---|---|---|---|
| Windows | ✗ | ✗ | ✗ |
| Linux | ✓ | ✗ | ✗ |
| OSX | ✓ | ✗ | ✗ |
| FreeBSD | ✓ | ✗ | ✗ |