CI(持續整合)——II
這篇文章作為上一篇的落地實現，會簡單介紹一下一些相關的概念以及基本的使用。採用的實現方案是GitLab結合Runner。
GitLab安裝教程
Runner
什麼是Runner
Runner是用來執行job(build、push等過程)並且將執行的結果傳送給Gitlab，方便使用者檢視結果的一個開源專案，它與Gitlab內建的Gitlab CI結合完成對應的job
Gitlab CI:是一套配合Gitlab使用的持續整合系統(也還有其他的持續整合系統，比如Jenkins)，目前8.0以後的gitlab版本預設整合Gitlab CI
安裝&註冊
Runner分類
specific runner
- specific runner只有自己可以使用，即使在同一專案組也無法使用，因為是通過token建立的個人環境
- share runner & group runner
供群組內部所有成員使用，管理員才有許可權進行相應的配置
Executor
用來執行job，並返回執行結果，有下面幾個分類
Executor分類
- SSH
在所有的executor中，對SSH的支援最少，可以使Gitlab Runner連線其他外部伺服器並在其他伺服器上執行build過程 - shell
配置最簡單的一種，所有構建所需要的依賴都會在安裝Runner時安裝好。這就意味著可以在任何一個安裝有Runner的本地機器的地方執行 - Virtual Machine Executor (VirtualBox / Parallels)
顧名思義，這種型別的executor允許在已經建立好的虛擬機器上執行build操作，這一型別可以使操作在不同作業系統上執行，以為它能夠使Gitlab Runner連線Windows、Linux以及其他作業系統的虛擬機器並在其上執行 - docker executor
是比較好的方式，因為使用這種方式使用更加簡便的方式(構建專案需要的所有依賴會統一放置在映象中)能使得build環境更加乾淨，使用依賴服務，docker executor會讓建立構建環境的過程更加容易 - docker machine
是一個特殊版本的docker executor，因為它支援自動排程。因為它會像普通的docker executor一樣工作，但是會按需建立構建主機 - kubernetes executor
這種方式允許使用現有的kubernetes叢集來進行構建操作，這種方式會通過呼叫kubernetes API為每個Gitlab CI job建立新的Pod(兼具構建容器和服務容器)
使用
使用Gitlab實現自動整合有兩個條件，
①在專案根目錄下有.gitlab-ci.yml檔案，可以使用其他檔名，但是需要自行配置
配置頁面：專案下找到settings -> CI/CD -> General pipelines展開 -> custom CI config path(預設使用.gitlab-ci.yml)
②為該專案配置了runner，如果沒有配置的話，在執行的時候會出現“stuck”樣的標籤來表示該專案未配置runner
.gitlab-ci.yml:這個檔案的作用是告訴runner怎麼執行整合操作，當執行push操作時，會在專案根目錄下查詢該檔案
.gitlab-ci.yml檔案編寫
一些基本概念
pipeline
相當於一次構建任務，裡面可以包括多個流程，如build、test等
stages：
翻譯成階段比較合適，用來全域性定義job(個人理解：就是提前宣告好stage,在下面定義的時候就可以使用stages下定義好的)，stages下定義的元素決定了job的執行順序
- 具有同樣stage的job會平行執行
- 當前一個stage必須成功執行完才會執行下一個
for example:
stages:
- build
- test
- deploy
上面的程式碼塊定義了三個階段
- 所有stage為build的job會平行執行
- 當stage為build的所有job都成功執行完，stage為test的job才會執行
- 同上，所有stage為test的job全部執行完，stage為deploy的job才會執行
- 當stage為deploy的job全部執行完，本次提交就會標記成pass，如果出現其中一個job失敗，那麼本次操作就會失敗，而且之後的job都不會執行
- stages結點的注意事項
- 如果在.gitlab-ci.yml中沒有定義stages也是可以的，提供了三個預設的stage，分別是build、test和deploy
- 如果一個job沒有指定stage，那麼這個job會指定stage為test
stage
stage定義了每一個job並且依賴於stages，它可以使一組job使用不同的stage
job
表示具體的構建工作，表示某個stage裡執行的具體工作，同一個stage可以對應多個job，相同stage的job會並行執行，這個在前面說過了，所以可以有下面的圖
script
- script是唯一一個定義job必須的關鍵字，它是一個由runner執行的shell指令碼，但是有時候需要加雙引號，當使用下面的特殊字元時需要注意：
:, {, }, [, ], ,, &, *, #, ?, |, -, <, >, =, !, %, @, `
only & expect
這兩個引數是用來設定job建立時機的
- only - job在哪個分支或者tag(標籤)發生變動時執行
- except - 與only相反
使用規則：
cache
cache && Job.cache
要求: GitLab Runner 0.7.0+
定義需要快取的檔案。每個 Job 開始的時候，Runner 都會刪掉 .gitignore 裡面的檔案。如果有些檔案 (如 node_modules/) 需要多個 Jobs 共用的話，我們只能讓每個 Job 都先執行一遍 npm install。
這樣很不方便，因此我們需要對這些檔案進行快取。快取了的檔案除了可以跨 Jobs 使用外，還可以跨 Pipeline 使用。
注意點
Runner的版本最好和Gitlab的版本一致，即使能夠正常使用，但是可能會有隱藏的問題