從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 | ✓ | ✗ | ✗ |