Gitlab-ci: 從零開始的前端自動(dòng)化部署

目錄

一.概念介紹
  1.1 gitlab-ci && 自動(dòng)化部署工具的運(yùn)行機(jī)制
  1.2 自動(dòng)化部署給我們帶來的好處

二.知識(shí)預(yù)備
  2.1 gitlab-ci涉及的抽象概念(Runner/PipeLine/Executor/Job )
  2.2 YML文件的基本語法規(guī)則
  2.3 .gitlab-ci.yml配置的特定關(guān)鍵字

三.CI實(shí)戰(zhàn)
  3.1 編寫一個(gè)gitlab-ci的“hello world”

四.坑點(diǎn)總結(jié)

五.gitlab-ci進(jìn)階
  5.1 YML的片段復(fù)用和模塊化
  5.2 gitlab-ci提供的其他配置關(guān)鍵字

一.概念介紹

1.1 gitlab-ci && 自動(dòng)化部署工具的運(yùn)行機(jī)制

以gitlab-ci為例：

(1) 通過在項(xiàng)目根目錄下配置 .gitlab-ci.yml 文件，可以控制ci流程的不同階段，例如install/檢查/編譯/部署服務(wù)器。gitlab平臺(tái)會(huì)掃描.gitlab-ci.yml文件，并據(jù)此處理ci流程

(2) ci流程在每次團(tuán)隊(duì)成員push/merge后之后觸發(fā)。每當(dāng)你push/merge一次，gitlab-ci都會(huì)檢查項(xiàng)目下有沒有.gitlab-ci.yml文件，如果有，它會(huì)執(zhí)行你在里面編寫的腳本，并完整地走一遍從intall => eslint檢查=>編譯 =>部署服務(wù)器的流程

(3)gitlab-ci提供了指定ci運(yùn)行平臺(tái)的機(jī)制，它提供了一個(gè)叫gitlab-runner的軟件，只要在對(duì)應(yīng)的平臺(tái)(機(jī)器或docker)上下載并運(yùn)行這個(gè)命令行軟件，并輸入從gitlab交互界面獲取的token,就可以把當(dāng)前機(jī)器和對(duì)應(yīng)的gitlab-ci流程綁定，也即：每次跑ci都在這個(gè)平臺(tái)上進(jìn)行。

(4).gitlab-ci的所有流程都是可視化的，每個(gè)流程節(jié)點(diǎn)的狀態(tài)可以在gitlab的交互界面上看到，包括執(zhí)行成功或失敗。如下圖所示,因?yàn)樗膱?zhí)行看上去就和多節(jié)管道一樣，所以我們通常用“pipeLine”來稱呼它

(5).不同push/merge所觸發(fā)的CI流程不會(huì)互相影響，也就是說，你的一次push引發(fā)的CI流程并不會(huì)因?yàn)榻酉聛砹硪晃煌碌膒ush而阻斷，它們是互不影響的。這一個(gè)特點(diǎn)方便讓測(cè)試同學(xué)根據(jù)不同版本進(jìn)行測(cè)試。

(6)pipeline不僅能被動(dòng)觸發(fā)，也是可以手動(dòng)觸發(fā)的。

??

1.2 自動(dòng)化部署給我們帶來的好處

自動(dòng)化部署的好處體現(xiàn)在幾個(gè)方面

1.提高前端的開發(fā)效率和開發(fā)測(cè)試之間的協(xié)調(diào)效率

Before

如果按照傳統(tǒng)的流程，在項(xiàng)目上線前的測(cè)試階段，前端同學(xué)修復(fù)bug之后，要手動(dòng)把代碼部署之后。才能通知測(cè)試同學(xué)在測(cè)試環(huán)境進(jìn)行測(cè)試。

這會(huì)造成幾個(gè)問題：本身手動(dòng)部署服務(wù)的工作是比較繁瑣的，占用了開發(fā)時(shí)間。同時(shí)開發(fā)-測(cè)試之間的環(huán)節(jié)的耦合問題，則會(huì)增加團(tuán)隊(duì)溝通成本。

After

通過gitlab-ci，前端開發(fā)在提交代碼之后就不用管了，ci流程會(huì)自動(dòng)部署到測(cè)試或集成環(huán)境的服務(wù)器。很大程度上節(jié)約了開發(fā)的時(shí)間。

同時(shí)，因?yàn)殚_發(fā)和測(cè)試人員可以共用gitlab里的pipeline界面, 測(cè)試同學(xué)能夠隨時(shí)把握代碼部署的情況，同時(shí)還可以通過交互界面手動(dòng)啟動(dòng)pipeline，自己去部署測(cè)試，從而節(jié)約和開發(fā)之間的溝通時(shí)間。

2.從更細(xì)的粒度把握代碼質(zhì)量

我們可以把eslint或其他的代碼檢查加到pipeline流程中，每當(dāng)團(tuán)隊(duì)成員提交和合并一次，pipeline都會(huì)觸發(fā)一次并對(duì)代碼做一次全面檢測(cè)，這樣就從一個(gè)更細(xì)的粒度上控制代碼質(zhì)量了。

二.知識(shí)預(yù)備

介紹完gitlab-ci的基本概念，接下來我將會(huì)介紹編寫一個(gè)gitlab-ci用例所需要的知識(shí)。這是在實(shí)戰(zhàn)之前的一點(diǎn)準(zhǔn)備工作，主要包括三部分

• gitlab-ci涉及的抽象概念
• YML文件的基本語法規(guī)則
• .gitlab-ci.yml配置的特定關(guān)鍵字

2.1 gitlab-ci涉及的抽象概念

首先要了解的是gitlab-ci中涉及的一些基本概念

1.Pipeline & Job

Pipeline是Gitlab根據(jù)項(xiàng)目的.gitlab-ci.yml文件執(zhí)行的流程，它由許多個(gè)任務(wù)節(jié)點(diǎn)組成, 而這些Pipeline上的每一個(gè)任務(wù)節(jié)點(diǎn)，都是一個(gè)獨(dú)立的Job

Job在YML中的配置我們將會(huì)在下面介紹，現(xiàn)在需要知道的是：每個(gè)Job都會(huì)配置一個(gè)stage屬性，來表示這個(gè)Job所處的階段。

一個(gè)Pipleline有若干個(gè)stage,每個(gè)stage上有至少一個(gè)Job，如下圖所示：

2.Runner

Runner可以理解為：在特定機(jī)器上根據(jù)項(xiàng)目的**.gitlab-ci.yml文件，對(duì)項(xiàng)目執(zhí)行pipeline的程序**。Runner可以分為兩種：Specific Runner 和 Shared Runner

• Shared Runner是Gitlab平臺(tái)提供的免費(fèi)使用的runner程序，它由Google云平臺(tái)提供支持，每個(gè)開發(fā)團(tuán)隊(duì)有十幾個(gè)。對(duì)于公共開源項(xiàng)目是免費(fèi)使用的，如果是私人項(xiàng)目則有每月2000分鐘的CI時(shí)間上限。
• Specific Runner是我們自定義的，在自己選擇的機(jī)器上運(yùn)行的runner程序，gitlab給我們提供了一個(gè)叫g(shù)itlab-runner的命令行軟件，只要在對(duì)應(yīng)機(jī)器上下載安裝這個(gè)軟件，并且運(yùn)行g(shù)itlab-runner register命令，然后輸入從gitlab-ci交互界面獲取的token進(jìn)行注冊(cè), 就可以在自己的機(jī)器上遠(yuǎn)程運(yùn)行pipeline程序了。

Gitlab-runner下載鏈接：https://docs.gitlab.com/runner/install/

Shared Runner 和 Specific Runner的區(qū)別

1. Shared Runner是所有項(xiàng)目都可以使用的，而Specific Runner只能針對(duì)特定項(xiàng)目運(yùn)行
2. Shared Runner默認(rèn)基于docker運(yùn)行，沒有提前裝配的執(zhí)行pipeline的環(huán)境，例如node等。而Specific Runner你可以自由選擇平臺(tái)，可以是各種類型的機(jī)器，如Linux/Windows等，并在上面裝配必需的運(yùn)行環(huán)境，當(dāng)然也可以選擇Docker/K8s等
3. 私人項(xiàng)目使用Shared Runner受運(yùn)行時(shí)間的限制，而Specific Runner的使用則是完全自由的。

3.Executor

什么是Executor？我們上面說過 Specific Runner是在我們自己選擇的平臺(tái)上執(zhí)行的，這個(gè)平臺(tái)就是我們現(xiàn)在說到的“Executor”，我們?cè)谔囟C(jī)器上通過gitlab-runner這個(gè)命令行軟件注冊(cè)runner的時(shí)候，命令行就會(huì)提示我們輸入相應(yīng)的平臺(tái)類型。可供選擇的平臺(tái)一共有如下幾種，下面是一張它們各方面特點(diǎn)的比較表格

下面是表格的原文鏈接

參考鏈接：https://docs.gitlab.com/runner/executors/#selecting-the-executor

為了簡(jiǎn)單起見，我下面的實(shí)踐部分使用的是我自己的本地Mac機(jī)器作為Executor，并且在注冊(cè)時(shí)選擇“Shell”作為Executor類型。

2.2 YML文件的基本語法規(guī)則

CI流程的運(yùn)行控制，決定于項(xiàng)目根目錄下編寫的配置文件—— .gitlab-ci.yml，正因如此，我們需要掌握YML的基本語法規(guī)則。

YML是一種編寫配置文件的語言，比JSON更為簡(jiǎn)潔和方便，因此，我們首先要掌握的就是YML文件的編寫語法。

一份簡(jiǎn)單的YML文件長下面這個(gè)樣子：

install-job: # 注釋
  tags:
    - sss
  stage: install
  script:
    - npm install

從這里我們就可以看出：

• YML通過縮進(jìn)組織層級(jí)
• YML里允許通過#符號(hào)編寫注釋

在基本結(jié)構(gòu)上，YML和 JSON也類似

• JSON是由對(duì)象，數(shù)組，以及對(duì)象和數(shù)組的嵌套結(jié)構(gòu)組成的
• YML也是由對(duì)象，數(shù)組，以及對(duì)象和數(shù)組的嵌套結(jié)構(gòu)組成的。

如下所示：

YML中的數(shù)組寫法

colors
  - red
  - blue
  - yellow

相當(dāng)于JSON中的

{ "colors": ["red","blue","yellow"] }

YML中的對(duì)象寫法：

people:
  name: zhangsan
  age: 14

相當(dāng)于JSON中的

{
  "people": {
     "name": "zhangsan"
     "age": 14
  }
}

當(dāng)然也可以是數(shù)組和對(duì)象之間形成的嵌套結(jié)構(gòu)

a:
  b:
    - d
  c: e

相當(dāng)于

{
  "a": {
    "b": [ "d" ],
    "c": "e"
   }
}

從JSON到Y(jié)ML之間的過渡學(xué)習(xí)的注意要點(diǎn)：

• 你不再需要“{}”這種符號(hào)去區(qū)分層級(jí)邊界了，你需要考慮使用縮進(jìn)
• 這里可以使用注釋，用#符號(hào)
• 如果不涉及特殊符號(hào)比如“[”，你一般是不需要給YML中的字符串加雙引號(hào)或者單引號(hào)的（當(dāng)然加了也可以）

了解了這些，對(duì)于編寫一個(gè)gitlab-ci的hello world已經(jīng)沒有問題了。

當(dāng)然YML還有著比JSON更為豐富的功能，比如用”&"符號(hào)和"<<:*”符號(hào)可以實(shí)現(xiàn)的片段導(dǎo)入的功能，以及gitlab-ci提供的include關(guān)鍵字和extend關(guān)鍵字等提供的結(jié)構(gòu)編排功能。這些我將在最后面的小節(jié)中講解，這里暫時(shí)不多贅述

2.3 gitlab-ci.yml配置的特定關(guān)鍵字

在了解了YML文件的語法格式后，接下來需要了解的就是gitlab-ci獨(dú)特的配置關(guān)鍵字，這些關(guān)鍵字將在.gitlab-ci.yml中使用，并用來控制一個(gè)pipeline具體的運(yùn)作過程

gitlab提供了很多配置關(guān)鍵字，其中最基礎(chǔ)和常用的有這么幾個(gè)

• stages
• stage
• script
• tags

stages & stage

stages定義在YML文件的最外層，它的值是一個(gè)數(shù)組，用于定義一個(gè)pipeline不同的流程節(jié)點(diǎn)

例如我們定義如下:

stages: # 分段
  - install
  - eslint
  - build
  - deploy

則在Gitlab交互界面中能夠看到如下展示

我們上面說過：Job是pipeline的任務(wù)節(jié)點(diǎn)，它構(gòu)成了pipeline的基本單元

而stage/script/tags這三個(gè)關(guān)鍵字，都是作為Job的子屬性來使用的,如下所示，install就是我們定義的一個(gè)Job

install:
  tags:
    - sss
  stage: install
  script:
    - npm install

stage

是一個(gè)字符串，且是stages數(shù)組的一個(gè)子項(xiàng)，表示的是當(dāng)前的pipeline節(jié)點(diǎn)。

當(dāng)前stage的執(zhí)行情況能在交互面板上能看的清清楚楚：

• 正在執(zhí)行是藍(lán)色
• 尚未執(zhí)行是灰色
• 執(zhí)行成功是綠色
• 執(zhí)行失敗是紅色

??

script

它是當(dāng)前pipeline節(jié)點(diǎn)運(yùn)行的shell腳本（以項(xiàng)目根目錄為上下文執(zhí)行）。

這個(gè)script是我們控制CI流程的核心，我們所有的工作：從安裝，編譯到部署都是通過script中定義的shell腳本來完成的。

如果腳本執(zhí)行成功，pipeline就會(huì)進(jìn)入下一個(gè)Job節(jié)點(diǎn)，如果執(zhí)行失敗那么pipeline就會(huì)終止

tags

tags是當(dāng)前Job的標(biāo)記，這個(gè)tags關(guān)鍵字是很重要，因?yàn)間itlab的runner會(huì)通過tags去判斷能否執(zhí)行當(dāng)前這個(gè)Job

例如我們?cè)趃itlab的面板中能看到當(dāng)前激活的runner的信息

Gitlab項(xiàng)目首頁=> setting => CI/CD => Runners

??

上面的這個(gè)sss就是當(dāng)前Runner的tags，這意味著：這個(gè)runner只會(huì)執(zhí)行tag為sss的Job。 如果一個(gè)Job沒有tag或者tag不是sss,那么即使這個(gè)Runner是激活且空閑的，也不會(huì)去執(zhí)行！

基本的gitlab-ci關(guān)鍵字就介紹結(jié)束了，有了這些知識(shí)對(duì)于編寫一個(gè)gitlab-ci的”hello world”已經(jīng)足夠了。對(duì)于更多的關(guān)鍵字的相關(guān)知識(shí)，將在文章最后再進(jìn)行介紹

三.gitlab-ci實(shí)戰(zhàn)

3.1 編寫一個(gè)gitlab-ci的"hello world"

好，說了這么多終于到了實(shí)踐的部分了，請(qǐng)?jiān)徢懊娴膯拢旅嫖覍?huì)展示一下如何從零開始實(shí)踐一個(gè)gitlab-ci的Hello world:

1.在平臺(tái)上下載并安裝Gitlab-runner命令行

我是在Mac上跑的ci，所以下面的適用于OSX系統(tǒng)（如果是其他平臺(tái)，可自行參考以下官方鏈接中的相關(guān)資料）

參考資料：https://docs.gitlab.com/runner/install/

依次運(yùn)行：

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

備注：這個(gè)下載過程可能會(huì)很慢，你可以復(fù)制上面的鏈接到瀏覽器中翻墻下載，然后下載完畢再進(jìn)行后續(xù)處理

2.初始化gitlab-runner

cd ~
gitlab-runner install
gitlab-runner start

最后輸出如下，說明成功了。

??

3.注冊(cè)Runner

運(yùn)行完gitlab-runner start只是完成了初始化，接下來你還要通過注冊(cè)才能運(yùn)行runner

參考鏈接：https://docs.gitlab.com/runner/register/index.html

注冊(cè)runner只需要一條運(yùn)行命令：

sudo gitlab-runner register

然后寫入相應(yīng)的token,url和tag等相關(guān)信息，就注冊(cè)完畢了。

上面要求輸入的Runner綁定的token和url， 獲取方式如下：

Gitlab項(xiàng)目首頁=> setting => CI/CD => Runners => Specific Runners

4.激活Runner

注冊(cè)完了可能還需要激活，這時(shí)我們可以看下面板，如果有個(gè)黑色的感嘆號(hào)，這說明runner注冊(cè)成功了，但是尚未激活（如果是綠色的說明已經(jīng)激活，本步驟跳過）

激活方法是本地運(yùn)行：

sudo gitlab-runner verify

輸出

??

這時(shí)候回去看Gitlab面板里的Runner參數(shù)：

是綠色就說明激活成功了

5.梳理和規(guī)劃Pipeline的不同階段和過程

在編寫.gitlab-ci.yml前，首先需要考慮的是我們的pipeline分幾個(gè)階段處理。

從前端工程師的角度出發(fā)，一個(gè)前端項(xiàng)目的PipeLine處理包括以下階段

<1> install階段

就是執(zhí)行npm install命令,根據(jù)package.json安裝node_modules依賴包

<2> eslint階段

執(zhí)行eslint檢查，判斷代碼格式是否符合規(guī)范，如果不符合則pipeline終止。

在這之前，我先通過npm install eslint安裝了eslint檢查工具，然后在項(xiàng)目根目錄下配置了.eslintrc文件。這部分可自行參考相關(guān)資料，這里暫不多贅述。

<3>build階段

編譯生成生產(chǎn)代碼，可以通過webpack之類的打包工具執(zhí)行編譯。當(dāng)然可以通過框架提供的編譯命令進(jìn)行編譯，例如我這個(gè)示例項(xiàng)目是用 react-scripts腳手架搭建的，所以通過npx react-scripts build進(jìn)行編譯。

<4>deploy階段

deploy也就是部署階段，也就是把剛才bulid階段生成的生產(chǎn)代碼，部署到生產(chǎn)訪問的服務(wù)器上。這里又具體有以下兩部分工作要做

A.申請(qǐng)服務(wù)器 & 安裝web服務(wù) (準(zhǔn)備工作)

（1）我本次使用的是百度云的云服務(wù)器(每天9點(diǎn)的時(shí)候可以搶有一定免費(fèi)使用期限的服務(wù)器)

（2）然后在本地終端通過ssh遠(yuǎn)程登陸服務(wù)器，并安裝apache以提供web服務(wù)

sudo apt-get install apache2

（3）然后，安裝完后的apache會(huì)在服務(wù)器下新增**/var/www/html/**目錄， 這個(gè)目錄就是存放網(wǎng)站資源的位置。

（4）最后我們只需要在每次部署的時(shí)候把生產(chǎn)的單頁面拷貝到這個(gè)頁面下，就能在瀏覽器上通過對(duì)應(yīng)的 IP+路徑 來訪問Web頁面了。

B. 部署資源（每次pipeline都進(jìn)行）

我下面的示例中，是通過 scp 這一命令，將本地機(jī)器代碼遠(yuǎn)程拷貝到云服務(wù)器上。

因?yàn)檫@一命令需要輸入密碼，所以通過 sshpass 命令攜帶密碼再執(zhí)行scp：

sshpass -p $PASSWORD scp -r ./build $CUSTOM_USERNAME@$CUSTOM_IP:/var/www/html

這里說明一下，Gitlab有自定義變量的功能，例如我們覺得直接在YML中寫入密碼/賬號(hào)等信息不太好，那么可以通過美元符號(hào)$寫入一個(gè)預(yù)定義的變量，然后在Gitlab面板上輸入它

7.編寫.gitlab-ci.yml配置文件

回顧一下之前YML語法規(guī)則和gitlab-ci配置關(guān)鍵字的知識(shí)，就不難編寫出以下YML文件

stages:?#?分段
??-?install
??-?eslint
??-?build
??-?deploy

cache:?#?緩存
??paths:
????-?node_modules
????-?build

install-job:
??tags:
????-?sss
??stage:?install
??script:
????-?npm?install

eslint-job:
??tags:
????-?sss
??stage:?eslint
??script:
????-?npm?run?eslint

build-job:
??tags:
????-?sss
??stage:?build
??script:
????-?npm?run?build

deploy-job:
??tags:
????-?sss
??stage:?deploy
??script:
????-?sshpass?-p?$PASSWORD?scp?-r?./build?$CUSTOM_USERNAME@$CUSTOM_IP:/var/www/html

package.json如下

{
??...
??"scripts":?{
????"start":?"react-scripts?start",
????"build":?"npx?react-scripts?build",
????"eslint":?"eslint?./src",
??},
??....
}

8.提交項(xiàng)目代碼

OK！終于到最后一步了，commit然后push

可以看到運(yùn)行如下

跑完后

最后輸入我們部署的IP看看我們部署的網(wǎng)頁

??

發(fā)現(xiàn)已經(jīng)把我們的項(xiàng)目代碼部署上去了

四. Gitlab-ci坑點(diǎn)詳解

說多了都是淚。。。。。

下面總結(jié)一下使用過程中遇到的典型坑點(diǎn)

1.Runner未激活問題

有時(shí)候注冊(cè)之后，查看面板上的Runner信息，可能會(huì)發(fā)現(xiàn)Runner處在未激活狀態(tài)

解決方法：

運(yùn)行以下命令重新啟動(dòng)runner

sudo gitlab-runner verify
sudo gitlab-runner restart

2.Job一直掛起，沒有Runner來處理

1.首先考慮的是不是Runner沒有激活，如果沒有那么按上面方式處理

2.還可能是tag沒有匹配到，上面說過，Runner注冊(cè)時(shí)是要填寫綁定tag的，如果你在YML里面編寫Job沒有帶上tag是不會(huì)有自定義Runner來處理。解決方法:給Job加tags

3.最后一種可能：你連續(xù)注冊(cè)了多個(gè)Runner,這些Runner沖突了，或者是新注冊(cè)的Runner和舊Runner使用了同一個(gè)token,這時(shí)候的解決方法如下：

先刪掉本地其他舊的Runner

sudo gitlab-runner unregister --all-runners

然后重置token,并使用更新后的token重新注冊(cè)一個(gè)Runner

3.specific Runner被Share Runner搶占了Job

有時(shí)候你可能會(huì)發(fā)現(xiàn)：你的Job并沒有被你新建的Runner執(zhí)行，而是被Share Runner搶先執(zhí)行了。你如果不想要Share Runner，你可以在Gitlab面板上關(guān)掉

五.gitlab-ci進(jìn)階

5.1 YML的片段復(fù)用和模塊化

上面我們編寫了gitlab-ci的 "hello world" 。但在實(shí)際項(xiàng)目的運(yùn)行中，.gitlab-ci.yml的編寫可能會(huì)漸趨復(fù)雜。那么這個(gè)時(shí)候YML的一些其他語法功能就派上用場(chǎng)了，上面我們將JSON和YML的基本結(jié)構(gòu)做比較并發(fā)現(xiàn)它們的相似之處，但實(shí)際上， YML提供了比JSON更為豐富的功能。

YML的片段復(fù)用功能

試思考：如果有一段配置片段會(huì)被很多Job使用，那么如果重復(fù)寫入片段，則會(huì)使我們的YML文件變得過分冗長。

而如果能把這段提前進(jìn)行定義，并根據(jù)別名進(jìn)行導(dǎo)入，就能讓YML文件簡(jiǎn)潔很多了。

YML的語法天然提供了這個(gè)功能:

• 使用 **&**符號(hào)可以定義一個(gè)片段的別名
• 使用 **<<**符號(hào)和 * 符號(hào)可以將別名對(duì)應(yīng)的YML片段導(dǎo)入

.common-config:?&commonConfig
??only:?#?表示僅在develop/release分支上執(zhí)行
????refs:
??????-?develop
??????-?release

install-job:
??#?其他配置?....
??<<:?*commonConfig
build-job:
??#?其他配置?....
??<<:?*commonConfig

YML的模塊化功能

試思考，如果我們配置腳本很長的話，我們一定要把它寫在.gitlab-ci.yml這單獨(dú)一個(gè)文件里嗎？

能否將它分成多個(gè)yml文件，然后把其他YML文件導(dǎo)入到入口YML文件(.gitlab-ci.yml)中呢。

gitlab-ci提供的include關(guān)鍵字便可實(shí)現(xiàn)這個(gè)功能, 它可以用來導(dǎo)入外部的YML文件。

例如我們有如下的YML結(jié)構(gòu)

 ├── .gitlab-ci.h5.yml'
 ├── .gitlab-ci.bd.yml'
 ├── .gitlab-ci.wx.yml
 └── .gitlab-ci.yml

那么在.gitlab-ci.yml中這么寫，就可以對(duì)它們做合并

include:
??-?'/.gitlab-ci.wx.yml'
??-?'/.gitlab-ci.bd.yml'
??-?'/.gitlab-ci.h5.yml'

gitlab-ci還提供了extend關(guān)鍵字，它的功能和前面提到的YML的片段導(dǎo)入的功能是一樣的，

不過可讀性更好一些。

.common-config:?
??only:?#?表示僅在develop/release分支上執(zhí)行
????refs:
??????-?develop
??????-?release

install-job:
??#?其他配置?....
??extends:?.common-config

build-job:
??#?其他配置?....
??extends:?.common-config

5.2 Gitlab-ci的其他配置項(xiàng)

cache關(guān)鍵字

cache關(guān)鍵字是需要特別著重講的一個(gè)關(guān)鍵字。顧名思義，它是用來做緩存的。

為什么要做緩存呢？當(dāng)然是為了重復(fù)運(yùn)行pipeline的時(shí)候不會(huì)重復(fù)安裝全部node_modules的包，從而減少pipeline的時(shí)間，提高pipeline的性能。

但是，這并不是cache關(guān)鍵字唯一的功能！

在介紹cache的另外一個(gè)功能之前，我要先說一下gitlab-ci的一個(gè)優(yōu)點(diǎn)“惡心人”的特點(diǎn)：

它在運(yùn)行下一個(gè)Job的時(shí)候，會(huì)默認(rèn)把前一個(gè)Job新增的資源刪除得干干靜靜

沒錯(cuò)，也就是說，我們上面bulid階段編譯生成的包，會(huì)在deploy階段運(yùn)行前被默認(rèn)刪除！（我生產(chǎn)包都沒了我怎么部署emmmmmmm）

而cache的作用就在這里體現(xiàn)出來了：如果我們把bulid生產(chǎn)的包的路徑添加到cache里面，雖然gitlab還是會(huì)刪除bulid目錄，但是因?yàn)樵趧h除前我們已經(jīng)重新上傳了cache，并且在下個(gè)Job運(yùn)行時(shí)又把cache給pull下來，那么這個(gè)時(shí)候就可以實(shí)現(xiàn)在下一個(gè)Job里面使用前一個(gè)Job的資源了

總而言之，cache的功能體現(xiàn)在兩點(diǎn)：

• 在不同pipeline之間重用資源
• 在同一pipeline的不同Job之間重用資源

雖然cache會(huì)緩存舊的包，但我們并不用擔(dān)心使用到舊的資源，因?yàn)閚pm install還是會(huì)如期運(yùn)行，并檢查package.json是否有更新，npm build的時(shí)候，生成的build資源包也會(huì)覆蓋cache,并且在當(dāng)前Job運(yùn)行結(jié)束時(shí)，作為**"新的cache"**上傳

artifacts關(guān)鍵字

這個(gè)關(guān)鍵字的作用是：將生成的資源作為pipeline運(yùn)行成功的附件上傳，并在gitlab交互界面上提供下載

例如我們新增以下YML

Build-job:
??stage:?build
??script:
??-?'npm?run?build'
??artifacts:
????name:?'bundle'
????paths:?
??????-?build/

pipeline跑完后是這樣的：

image/services

這兩個(gè)關(guān)鍵字可使用Docker的鏡像和服務(wù)運(yùn)行Job，具體可參考Docker的相關(guān)資料,這里暫不多加敘述

only/except

這兩個(gè)關(guān)鍵字后面跟的值是tag或者分支名的列表。

故名思義

• only的作用是指定當(dāng)前Job僅僅只在某些tag或者branch上觸發(fā)
• 而except的作用是當(dāng)前Job不在某些tag或者branch上觸發(fā)

job:
??#?use?regexp
??only:
????-?/^issue-.*$/
????-?develop
????-?release

allow_failure

值為true/false, 表示當(dāng)前Job是否允許允許失敗。

• 默認(rèn)是false,也就是如果當(dāng)前Job因?yàn)閳?bào)錯(cuò)而失敗，則當(dāng)前pipeline停止
• 如果是true，則即使當(dāng)前Job失敗，pipeline也會(huì)繼續(xù)運(yùn)行下去。

job1:
??stage:?test
??script:
????-?execute_script_that_will_fail
??allow_failure:?true

retry

顧名思義，指明的是當(dāng)前Job的失敗重試次數(shù)的上限。

但是這個(gè)值只能在0 ～2之間，也就是重試次數(shù)最多為2次，包括第一次運(yùn)行在內(nèi)，Job最多自動(dòng)運(yùn)行3次

timeout

配置超時(shí)時(shí)間，超過時(shí)間判定為失敗

Job:
??script:?rspec
??timeout:?3h?30m

When

表示當(dāng)前Job在何種狀態(tài)下運(yùn)行，它可設(shè)置為3個(gè)值

• on_success: 僅當(dāng)先前pipeline中的所有Job都成功（或因?yàn)橐褬?biāo)記，被視為成功allow_failure）時(shí)才執(zhí)行當(dāng)前Job 。這是默認(rèn)值。
• on_failure: 僅當(dāng)至少一個(gè)先前階段的Job失敗時(shí)才執(zhí)行當(dāng)前Job。
• always: 執(zhí)行當(dāng)前Job，而不管先前pipeline的Job狀態(tài)如何。

》》面試官都在用的題庫，快來看看《《