持續集成(Continuous integration,簡稱CI)指的是,頻繁地(一天屢次)將代碼集成到主幹。node
GitLab CI
是 GitLab Continuous Integration
(Gitlab 持續集成)的簡稱。從 GitLab
的 8.0 版本開始,GitLab
就全面集成了 Gitlab-CI
,而且對全部項目默認開啓。只要在項目倉庫的根目錄添加 .gitlab-ci.yml
文件,而且配置了 Runner
(運行器),那麼每一次合併請求(MR)或者 push
都會觸發 CI pipeline
。git
若是一切運行正常,你將獲得與 commit 關聯的標記。如圖:github
一次 Pipeline
其實至關於一次構建任務,裏面能夠包含多個流程,如安裝依賴、運行測試、編譯、部署測試服務器、部署生產服務器等流程。 任何提交或者 Merge Request 的合併均可以觸發 Pipeline
,以下圖所示:docker
+------------------+ +----------------+
| | trigger | |
| Commit / MR +---------->+ Pipeline |
| | | |
+------------------+ +----------------+
複製代碼
Stages
表示構建階段,說白了就是上面提到的流程。 咱們能夠在一次 Pipeline
中定義多個 Stages
,這些 Stages
會有如下特色:shell
Stages
會按照順序運行,即當一個 Stage
完成後,下一個 Stage
纔會開始Stages
完成後,該構建任務 (Pipeline
) 纔會成功Stage
失敗,那麼後面的 Stages
不會執行,該構建任務 (Pipeline
) 失敗所以,Stages
和 Pipeline
的關係就是:npm
+--------------------------------------------------------+
| |
| Pipeline |
| |
| +-----------+ +------------+ +------------+ |
| | Stage 1 |---->| Stage 2 |----->| Stage 3 | |
| +-----------+ +------------+ +------------+ |
| |
+--------------------------------------------------------+
複製代碼
Jobs
表示構建工做,表示某個 Stage 裏面執行的工做。 咱們能夠在 Stages
裏面定義多個 Jobs
,這些 Jobs
會有如下特色:vim
Stage
中的 Jobs
會並行執行Stage
中的 Jobs
都執行成功時,該 Stage 纔會成功Job
失敗,那麼該 Stage
失敗,即該構建任務 (Pipeline
) 失敗因此,Jobs
和 Stage
的關係圖就是:ruby
+------------------------------------------+
| |
| Stage 1 |
| |
| +---------+ +---------+ +---------+ |
| | Job 1 | | Job 2 | | Job 3 | |
| +---------+ +---------+ +---------+ |
| |
+------------------------------------------+
複製代碼
安裝環境爲
Ubuntu 16.04.4 LTS (GNU/Linux 4.4.0-105-generic x86_64)
,docker
版本爲Docker version 18.03.1-ce, build 9ee9f40
bash
gitlab-ci-multi-runner
# For Debian/Ubuntu
curl -L https://packages.gitlab.com/install/repositories/runner/gitlab-ci-multi-runner/script.deb.sh | sudo bash
# For RHEL/CentOS
curl -L https://packages.gitlab.com/install/repositories/runner/gitlab-ci-multi-runner/script.rpm.sh | sudo bash
複製代碼
docker images
sudo docker images
複製代碼
.gitlab-ci.yml
文件,文件代碼以下:
stages
定義Stages
,默認有三個Stages
,分別是build
,test
,deploy
。Job.only
定義只有develop
分支會觸發相關的Jobs
。服務器
stages:
- build
job1:
# 是否開啓 debug 模式
# variables:
# CI_DEBUG_TRACE: "true"
stage: build
tags:
- 新建 runner 的標籤
only:
- develop
script:
- cd public
- npm i
- npm run build
複製代碼
pipeline
配置頁面URL
和 Token
,留以註冊 runner
使用runner
,runner
註冊成功以後,你會在 pipeline
配置頁面看見 specific runners
下多出了你剛新增的 runner
。sudo gitlab-ci-multi-runner register
# Please enter the gitlab-ci coordinator URL (e.g. https://gitlab.com )
你的 URL
# Please enter the gitlab-ci token for this runner
你的 Token
# Please enter the gitlab-ci description for this runner
my-runner
# Please enter the gitlab-ci tags for this runner (comma separated)
my-runner
Whether to run untagged builds [true/false]:
false
Whether to lock Runner to current project [true/false]:
false
# Please enter the executor: shell, docker, docker-ssh, ssh?
docker
# Please enter the Docker image (eg. ruby:2.1):
node:9.4.0
複製代碼
runner
sudo gitlab-ci-multi-runner unregister --url url地址 --token tocken值
複製代碼
runner
狀態sudo gitlab-ci-multi-runner status
複製代碼
runner
列表sudo gitlab-ci-multi-runner list
複製代碼
runner
配置文件sudo vim /etc/gitlab-runner/config.toml
複製代碼
切換到項目 Pipelines
頁面,發現出現如下狀況,則表明你的 runner
已經配置完成,你的每一次提交都會觸發 runner
。
使用 GitLab CI 克隆私有倉庫時候,會提示 Host key verification failed
。
須要作以下配置,Key
寫入 SSH_PRIVATE_KEY
,Value
寫入 服務器 private SSH key
。而後在 .gitlab-ci.yml
文件前面寫入以下代碼,並保存。
```powershell
before_script:
- 'which ssh-agent || ( apt-get update -y && apt-get install openssh-client -y )'
# Run ssh-agent (inside the build environment)
- eval $(ssh-agent -s)
# Add the SSH key stored in SSH_PRIVATE_KEY variable to the agent store
- ssh-add <(echo "$SSH_PRIVATE_KEY")
- mkdir -p ~/.ssh
- '[[ -f /.dockerenv ]] && echo -e "Host *\n\tStrictHostKeyChecking no\n\n" > ~/.ssh/config'
```
複製代碼