GitLab CI/CD 介紹和使用

一、持續集成介紹

持續集成是一種軟件開發實踐，即團隊開發成員經常集成他們的工作，通常每個成員每天至少集成一次，也就意味着每天可能會發生多次集成。每次集成都通過自動化的構建（包括編譯，發佈，自動化測試)來驗證，從而儘快地發現集成錯誤。許多團隊發現這個過程可以大大減少集成的問題，讓團隊能夠更快的開發內聚的軟件。—— Martin Fowler

1 概念

• 持續集成(Continuous Integration)：**頻繁地(一天多次)將代碼集成到主幹。**讓產品可以快速迭代，同時還能保持高質量。它的核心措施是，代碼集成到主幹之前，必須通過自動化測試。只要有一個測試用例失敗，就不能集成。“持續集成並不能消除 Bug，而是讓它們非常容易發現和改正。”
• 持續交付(Continuous Delivery)：**頻繁地將軟件的新版本，交付給質量團隊或者用戶，以供評審。**如果評審通過，代碼就進入生產階段。持續交付可以看作持續集成的下一步。它強調的是，不管怎麼更新，軟件是隨時隨地可以交付的。
• 持續部署(continuous Deployment)：**代碼通過評審以後，自動部署到生產環境。**是持續部署是持續交付的下一步，持續部署的目標是，代碼在任何時刻都是可部署的，可以進入生產階段。

2 持續集成的好處

• 自動化構建且狀態對每個人可見。可以使用Maven、Gradle等來實現自動化構建，可以在構建過程中實現自動化測試（前提是有寫單元測試用例）。集成服務器在持續集成過程中發現問題可以及時發送警告給相關的干係人。
• **解放了重複性勞動。**自動化部署工作可以解放集成、測試、部署等重複性勞動，而機器集成的頻率明顯比手工高很多。
• **更快地發現和修復問題。**持續集成更早的獲取變更，更早的進入測試，更早的發現問題，解決問題的成本顯著下降。
• **更快的交付成果。**更早發現錯誤減少解決錯誤所需的工作量。集成服務器在構建環節發現錯誤可以及時通知開發人員修復。集成服務器在部署環節發現錯誤可以回退到上一版本，服務器始終有一個可用的版本。
• **減少手工的錯誤。**在重複性動作上，人容易犯錯，而機器犯錯的機率幾乎爲零。
• **減少了等待時間。**縮短了從開發、集成、測試、部署各個環節的時間，從而也就縮短了中間可以出現的等待時機。持續集成，意味着開發、集成、測試、部署也得以持續。
• **更高的產品質量。**集成服務器往往提供代碼質量檢測等功能，對不規範或有錯誤的地方會進行標緻，也可以設置郵件和短信等進行警告。

3 常用持續集成工具

• Jenkins
• GitLab CI
• TeamCity
• Travis CI
• Bamboo
• CircleCI
• …

二、Gitlab 持續集成

[外鏈圖片轉存失敗(img-93v8L3VB-1566115077727)(https://docs.gitlab.com/ee/ci/img/cicd_pipeline_infograph.png)]

1 概念介紹

(1) GitLab

GitLab 是一個利用Ruby on Rails開發的開源應用程序，實現一個自託管的 Git 項目倉庫，可通過 Web 界面進行訪問公開的或者私人項目。它擁有與GitHub類似的功能，能夠瀏覽源代碼，管理缺陷和註釋。可以管理團隊對倉庫的訪問，它非常易於瀏覽提交過的版本並提供一個文件歷史庫。

(2) GitLab CI/CD

GitLab CI/CD 是GitLab Continuous Integration（Gitlab持續集成）的簡稱。GitLab 自GitLab 8.0開始提供了持續集成的功能，且對所有項目默認開啓。只要在項目倉庫的根目錄添加.gitlab-ci.yml文件，並且配置了Runner（運行器），那麼每一次push或者合併請求（Merge Request）都會觸發CI Pipeline。

(3) GitLab Runner

GitLab Runner GitLab Runner是一個開源項目，可以運行在 GNU / Linux，macOS 和 Windows 操作系統上。每次push的時候 GitLab CI 會根據.gitlab-ci.yml配置文件運行你流水線（Pipeline）中各個階段的任務（Job），並將結果發送回 GitLab。GitLab Runner 是基於 Gitlab CI 的 API 進行構建的相互隔離的機器（或虛擬機）。GitLab Runner 不需要和 Gitlab 安裝在同一臺機器上，且考慮到 GitLab Runner 的資源消耗問題和安全問題，也不建議這兩者安裝在同一臺機器上。

Gitlab Runner 分爲三種：

• 共享Runner(Shared runners)
• 專享Runner(Specific runners)
• 分組Runner(Group Runners)

(4) Pipelines

Pipelines 中文稱爲流水線，是分階段執行的構建任務。如：安裝依賴、運行測試、打包、部署開發服務器、部署生產服務器等流程。每一次push或者Merge Request都會觸發生成一條新的Pipeline。

下面是流水線示例圖：

[外鏈圖片轉存失敗(img-HjJVfv6x-1566115077729)(https://docs.gitlab.com/ce/ci/img/pipelines_index.png)]

(5) Stages

Stages 表示構建階段，可以理解爲上面所說“安裝依賴”、“運行測試”等環節的流程。我們可以在一次 Pipeline 中定義多個 Stages，這些 Stages 會有以下特點：

• 所有 Stages 會按照順序運行，即當一個 Stage 完成後，下一個 Stage 纔會開始（當然可以在.gitlab-ci.yml文件中配置上一階段失敗時下一階段也執行）
• 只有當所有 Stages 完成後，該構建任務 (Pipeline) 纔會成功
• 如果任何一個 Stage 失敗，那麼後面的 Stages 不會執行，該構建任務 (Pipeline) 失敗

下面是一個流水線內的階段任務示例圖：

[外鏈圖片轉存失敗(img-ipwGJWAg-1566115077730)(https://docs.gitlab.com/ce/ci/img/pipelines.png)]

(6) Jobs

Jobs 表示構建的作業（或稱之爲任務），表示某個 Stage 裏面執行的具體任務。我們可以在 Stages 裏面定義多個 Jobs，這些 Jobs 會有以下特點：

• 相同 Stage 中的 Jobs 無執行順序要求，會並行執行
• 相同 Stage 中的 Jobs 都執行成功時，該 Stage 纔會成功
• 如果任何一個 Job 失敗，那麼該 Stage 失敗，即該構建任務 (Pipeline) 也失敗（可以在.gitlab-ci.yml文件中配置允許某 Job 可以失敗，也算該 Stage 成功）

(7) .gitlab-ci.yml

GitLab 中默認開啓了 Gitlab CI/CD 的支持，且使用YAML文件.gitlab-ci.yml來管理項目構建配置。該文件需要存放於項目倉庫的根目錄（默認路徑，可在 GitLab 中修改），它定義該項目的 CI/CD 如何配置。所以，我們只需要在.gitlab-ci.yml配置文件中定義流水線的各個階段，以及各個階段中的若干作業（任務）即可。

下面是.gitlab-ci.yml文件的一個簡單的Hello World示例：

# 定義 test 和 package 兩個 Stages
stages:
  - test
  - package

# 定義 package 階段的一個 job
package-job:
  stage: package
  script:
    - echo "Hello, package-job"
    - echo "I am in package stage"

# 定義 test 階段的一個 job
test-job:
  stage: test
  script:
    - echo "Hello, test-job"
    - echo "I am in test stage"

以上配置中，用 stages 關鍵字來定義 Pipeline 中的各個構建階段，然後用一些非關鍵字來定義 jobs。每個 job 中可以可以再用 stage 關鍵字來指定該 job 對應哪個 stage。job 裏面的script關鍵字是每個 job 中必須要包含的，它表示每個 job 要執行的命令。

注：猜猜上面例子的運行結果？

(8) Badges

Badges 即：徽章，當 Pipelines 執行過程中或者執行完成時會生成徽章，你可以將這些徽章加入到你的README.md文件中，便於從倉庫主頁看到最新的構建狀態。

徽章的鏈接形如下：

http://example.gitlab.com/namespace/project/badges/branch/build.svg 

我們用 GitLab 項目的徽章作爲例子，效果如下：

2 安裝 GitLab Runner

這裏有 GitLab Runner安裝相關的資源和文檔可供大家參考。以下僅以咱們公司常用的Centos爲例來做安裝說明。

(1) 在線安裝

# 添加官方的repo.
curl -L https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.rpm.sh | sudo bash

# yum 安裝Gtilab Runner.
sudo yum install gitlab-runner

(2) 離線安裝

# 安裝Git
sudo yum –y install git

# rpm離線安裝事先下載好的 Gitlab Runner rpm包.
rpm -ivh gitlab-runner-10.5.0-1.x86_64.rpm

注：Gitlab Runner 依賴了Git，所以，離線安裝 Gitlab Runner 之前得首先安裝Git，離線安裝包可以從這裏下載。

3 註冊 Gitlab Runner

安裝了 GitLab Runner 之後,就可以爲 GitLab 中的倉庫註冊一個 Runner，註冊的交互式命令如下：

sudo gitlab-runner register

命令的交互式的過程如下：

# 輸入註冊命令
sudo gitlab-runner register

# 輸入公司的 GitLab 網站地址
Please enter the gitlab-ci coordinator URL (e.g. https://gitlab.com )
http://gitlab.xxxx.com/

# 你項目倉庫的token，token可以在 Settings -> CI/CD -> Runners settings 中找到.
Please enter the gitlab-ci token for this runner
xxx

# 輸入描述這個 runner 的名稱
Please enter the gitlab-ci description for this runner
[hostame] my-runner

# 輸入 runner 的標籤
Please enter the gitlab-ci tags for this runner (comma separated):
my-tag,another-tag

# 輸入 runner 的執行器.
Please enter the executor: ssh, docker+machine, docker-ssh+machine, kubernetes, docker, parallels, virtualbox, docker-ssh, shell:
shell

以上流程註冊成功之後，就可以在你的項目倉庫中 Settings -> CI/CD -> Runners settings 看到這個 Runner 了。

4 Gitlab Runner 常用命令彙總

下面的表格中列出了一些常用的Gitlab Runner命令，以供參考：

命令	描述
gitlab-runner run	運行一個runner服務
gitlab-runner register	註冊一個新的runner
gitlab-runner start	啓動服務
gitlab-runner stop	關閉服務
gitlab-runner restart	重啓服務
gitlab-runner status	查看各個runner的狀態
gitlab-runner unregister	註銷掉某個runner
gitlab-runner list	顯示所有運行着的runner
gitlab-runner verify	檢查已註冊的運行程序是否可以連接到GitLab，但它不驗證GitLab Runner服務是否正在使用運行程序。

三、一個Web項目 CI/CD 簡單示例

接下來，用一個實際項目來演示 GitLab CI/CD 的配置和使用，其中主要包括：編譯測試、項目打包、部署服務、Sonar手動檢查、Sonar定時檢查五個階段。

下面用一個傳統的 Java web 項目(這裏稱之爲cidemo)和Tomcat來作爲示例，並用來展示常用配置的使用。當我每次push代碼或者Merge Request時，都會生成一條流水線，且會自動執行我們上面所說的一些階段，而Sonar手動檢查我們設置爲手動操作，且再額外配置Sonar定時檢查的任務。

注：我 Gitlab Runner 是安裝在Centos環境中，並使用的shell執行器。

# 定義stages
stages:
  - test
  - install
  - run
  - sonar

# 定義安裝包的存放位置和Tomcat服務器的地址的變量，便於後續部署使用.
variables:
  CIDEMO_PACKAGE_DIR: '/home/gitlab-runner/packages/cidemo/'
  SERVER_HOME_DIR: '/home/gitlab-runner/tomcat/cidemo-tomcat/'

###################### 構建編譯和單元測試的job. #######################

編譯測試任務:
  stage: test
  only:
    - branches
  script:
    - mvn clean test

###################### Maven安裝得到war包的job. #######################

打包任務:
  stage: install
  only:
    - develop
  script:
    - mvn install
    - echo '準備將最新的war包複製、保存到某個目錄裏面供後續使用.'
    - rm -rf $CIDEMO_PACKAGE_DIR/*.war
    - cp target/*.war $CIDEMO_PACKAGE_DIR/cidemo.war

####################### 部署運行war包的job. #######################

部署運行任務:
  stage: run
  only:
    - develop
  script:
    - echo '準備部署和運行war包！(爲了方便部署到了Tomcat中運行)'
    - cd $SERVER_HOME_DIR
    - sh bin/shutdown.sh
    - rm -rf webapps/cidemo.war
    - cp $CIDEMO_PACKAGE_DIR/cidemo.war $SERVER_HOME_DIR/webapps/cidemo.war
    - nohup sh ./bin/startup.sh > logs/cidemo_nohup.log 2>&1 &

###################### Sonar手動構建的job. #######################

Sonar手動檢查:
  stage: sonar
  when: manual
  only:
    - develop
  script:
    - echo '準備對項目代碼做sonar的質量檢查！'
    - mvn compile && mvn sonar:sonar -Dsonar.host.url=http://172.16.34.102:9000 -Dsonar.login=497a0e0e2fc07f64c4b54edc17bb47dfa251ba34

###################### Sonar每晚定時構建的job. #######################

Sonar定時檢查:
  stage: sonar
  only:
    - schedules
  script:
    - echo '開始定時對項目代碼做sonar的質量檢查！'
    - mvn compile && mvn sonar:sonar -Dsonar.host.url=http://172.16.34.102:9000 -Dsonar.login=497a0e0e2fc07f64c4b54edc17bb47dfa251ba34

四、Gitlab CI/CD yaml 常用配置介紹

開始構建之前.gitlab-ci.yml文件定義了一系列帶有約束說明的任務。這些任務都是以任務名開始並且至少要包含script部分，.gitlab-ci.yml允許指定無限量 jobs。每個 jobs 必須有一個唯一的名字，且名字不能是下面列出的保留字段：

• image
• services
• stages
• types
• before_script
• after_script
• variables
• cache

job由一列參數來定義 jobs 的行爲：

Keyword	Required	Description
script	yes	Runner執行的命令或腳本
extends	no	定義此作業將繼承的配置條目
image	no	所使用的docker鏡像，查閱使用docker鏡像
services	no	所使用的docker服務，查閱使用docker鏡像
stage	no	定義job stage（默認：test）
type	no	stage的別名（已棄用）
variables	no	定義job級別的變量
only	no	定義一列git分支，併爲其創建job
except	no	定義一列git分支，不創建job
tags	no	定義一列tags，用來指定選擇哪個Runner（同時Runner也要設置tags）
allow_failure	no	允許job失敗。失敗的job不影響commit狀態
when	no	定義何時開始job。可以是on_success，on_failure，always或者manual
dependencies	no	定義job依賴關係，這樣他們就可以互相傳遞artifacts
cache	no	定義應在後續運行之間緩存的文件列表
before_script	no	重寫一組在作業前執行的命令
after_script	no	重寫一組在作業後執行的命令
environment	no	定義此作業完成部署的環境名稱
coverage	no	定義給定作業的代碼覆蓋率設置
etry	no	定義在發生故障時可以自動重試作業的時間和次數
parallel	no	定義應並行運行的作業實例數

extends

是在 GitLab 11.3 中引入的。

extends定義了一個使用extends的作業將繼承的條目名稱。它是使用YAML錨點的替代方案，並且更加靈活和可讀：

.tests:
  script: rake test
  stage: test
  only:
    refs:
      - branches

rspec:
  extends: .tests
  script: rake rspec
  only:
    variables:
      - $RSPEC

在上面的示例中，rspec作業繼承自.tests模板作業。 GitLab 將根據鍵執行反向深度合併。 GitLab將：

• 將rspec內容以遞歸方式合併到.tests中。
• 不合並鍵的值。

這實際生成的是以下rspec作業：

rspec:
  script: rake rspec
  stage: test
  only:
    refs:
      - branches
    variables:
      - $RSPEC

注: rake test已被rake rspec腳本覆蓋。

image 和 services

這兩個關鍵字允許使用一個自定義的 Docker 鏡像和一系列的服務，並且可以用於整個 job 週期。詳細配置文檔請查看a separate document。

before_script 和 after_script

before_script用來定義所有 job 之前運行的命令，after_script用來定義所有 job 之後運行的命令。它們可以是一個數組或者是多行字符串。

stages

stages 用來定義可以被 job 調用的 stages。stages 的規範允許有靈活的多級 pipelines。

stages中的元素順序決定了對應job的執行順序：

1. 相同 stage 的 job 可以平行執行。
2. 下一個 stage 的 job 會在前一個 stage 的 job 成功後開始執行。

接下仔細看看這個例子，它包含了3個 stage：

stages:
 - build
 - test
 - deploy

1. 首先，所有 build 的 jobs 都是並行執行的。
2. 所有 build 的 jobs 執行成功後，test 的 jobs 纔會開始並行執行。
3. 所有 test 的 jobs 執行成功，deploy 的 jobs 纔會開始並行執行。
4. 所有的 deploy 的 jobs 執行成功，commit纔會標記爲success。
5. 任何一個前置的 jobs 失敗了，commit會標記爲failed並且下一個 stages 的 jobs 都不會執行。

這有兩個特殊的例子值得一提：

1. 如果.gitlab-ci.yml中沒有定義stages，那麼 job’s stages 會默認定義爲build，test和deploy。
2. 如果一個 job 沒有指定 stage，那麼這個任務會分配到 test stage。

only 和 except

only和except是兩個參數用分支策略來限制 jobs 構建：

• only定義哪些分支和標籤的git項目將會被job執行。
• except定義哪些分支和標籤的git項目將不會被job執行。

下面是refs策略的使用規則：

• only 和 except 可同時使用。如果only和except在一個 job 配置中同時存在，則以 only 爲準，跳過 except(從下面示例中得出)。
• only 和 except 可以使用正則表達式。
• only 和 except 允許使用特殊的關鍵字：branches，tags和triggers。
• only 和 except 允許使用指定倉庫地址但不是forks的倉庫(查看示例3)。

在下面這個例子中，job 將只會運行以issue-開始的refs(分支)，然而except中設置將被跳過。

job:
  # use regexp
  only:
    - /^issue-.*$/
  # use special keyword
  except:
    - branches

在下面這個例子中，job 將只會執行有tags的refs，或者通過API觸發器明確地請求構建。

job:
  # use special keywords
  only:
    - tags
    - triggers

下面這個例子將會爲所有的分支執行job，但 master 分支除外。

job:
  only:
    - branches@gitlab-org/gitlab-ce
  except:
    - master@gitlab-org/gitlab-ce

variables

GItLab CI 允許在.gitlab-ci.yml文件中添加變量，並在 job 環境中起作用。因爲這些配置是存儲在 git 倉庫中，所以最好是存儲項目的非敏感配置，例如：

variables:
  DATABASE_URL:"postgres://postgres@postgres/my_database"

這些變量可以被後續的命令和腳本使用。

除了用戶自定義的變量外，Runner 也可以定義它自己的變量。CI_COMMIT_REG_NAME就是一個很好的例子，它的值表示用於構建項目的分支或tag名稱。除了在.gitlab-ci.yml中設置變量外，還有可以通過 GitLab 的界面上設置私有變量。

這裏有更多關於variables的介紹。

cache

cache: paths

使用paths指令選擇要緩存的文件或目錄。也可以使用通配符。

如果 cache 定義在 jobs 的作用域之外，那麼它就是全局緩存，所有 jobs 都可以使用該緩存。

緩存binaries和.config中的所有文件：

rspec:
  script: test
  cache:
    paths:
    - binaries/
    - .config

緩存git中沒有被跟蹤的文件：

rspec:
  script: test
  cache:
    untracked: true

緩存binaries下沒有被git跟蹤的文件：

rspec:
  script: test
  cache:
    untracked: true
    paths:
    - binaries/

job 中優先級高於全局的。下面這個rspec job中將只會緩存binaries/下的文件：

cache:
  paths:
  - my/files

rspec:
  script: test
  cache:
    key: rspec
    paths:
    - binaries/

注意，緩存是在 jobs 之前進行共享的。如果你不同的 jobs 緩存不同的文件路徑，必須設置不同的cache:key，否則緩存內容將被重寫。緩存只是盡力而爲之，所以別期望緩存會一直存在。

cache: key

key指令允許我們定義緩存的作用域(親和性)，可以是所有 jobs 的單個緩存，也可以是每個 job，也可以是每個分支或者是任何你認爲合適的地方。它也可以讓你很好的調整緩存，允許你設置不同 jobs 的緩存，甚至是不同分支的緩存。

cache:key可以使用任何的預定義變量。

默認key是默認設置的這個項目緩存，因此默認情況下，從GitLab 9.0開始，每個 pipelines 和 jobs 中可以共享一切。

配置示例

緩存每個job：

cache:
  key: "$CI_JOB_NAME"
  untracked: true

緩存每個分支：

cache:
  key: "$CI_COMMIT_REF_NAME"
  untracked: true

緩存每個 job 且每個分支：

cache:
  key: "$CI_JOB_NAME/$CI_COMMIT_REF_NAME"
  untracked: true

緩存每個分支且每個stage：

cache:
  key: "$CI_JOB_STAGE/$CI_COMMIT_REF_NAME"
  untracked: true

如果使用的Windows Batch(windows批處理)來跑腳本需要用%替代$：

cache:
  key: "%CI_JOB_STAGE%/%CI_COMMIT_REF_NAME%"
  untracked: true

allow_failure

allow_failure可以用於當你想設置一個 job 失敗的之後並不影響後續的CI組件的時候。失敗的 jobs 不會影響到commit狀態。

當開啓了允許 job 失敗，所有的 intents 和 purposes 裏的 pipeline 都是成功/綠色，但是也會有一個"CI build passed with warnings"信息顯示在Merge Request或commit或job page。這被允許失敗的作業使用，但是如果失敗表示其他地方應採取其他（手動）步驟。

下面的這個例子中，job1和job2將會並列進行，如果job1失敗了，它也不會影響進行中的下一個 stage，因爲這裏有設置了allow_failure: true。

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

job2:
  stage: test
  script:
    - execute_script_that_will_succeed

job3:
  stage: deploy
  script:
    - deploy_to_staging

when

when用於實現在發生故障或儘管失敗時運行的作業。when可以設置以下值：

• on_success - 只有前面 stages 的所有工作成功時才執行。這是默認值。
• on_failure - 當前面 stages 中任意一個jobs失敗後執行。
• always - 無論前面 stages 中 jobs 狀態如何都執行。
• manual - 手動執行(GitLab8.10增加)。更多請查看手動操作。

artifacts

artifacts用於指定成功後應附加到 job 的文件和目錄的列表。只能使用項目工作間內的文件或目錄路徑。在job成功完成後artifacts將會發送到GitLab中，同時也會在 GitLab UI 中提供下載。如果想要在不通的 job 之間傳遞artifacts，請查閱依賴關係。以下是一些例子：

發送binaries和.config中的所有文件：

artifacts:
  paths:
  - binaries/
  - .config

發送所有沒有被Git跟蹤的文件：

artifacts:
  untracked: true

發送沒有被Git跟蹤和binaries中的所有文件：

artifacts:
  untracked: true
  paths:
  - binaries/

五、其他相關內容

1 API觸發器 Triggers

Triggers 可用於強制使用API調用重建特定分支，tag或commits。API的使用示例可以在Settings -> CI/CD -> Pipeline triggers中找到。

在triggers文檔中查看更多。

2 配置定時任務

GitLab CI 中可以在 GitLab Settings -> CI/CD -> Schedules中配置定時任務，點擊New Schedule按鈕，可以配置你流水線的定時執行任務，包括：描述信息、定時的Cron表達式、目標分支、變量等信息。

然後在需要定時執行的作業的only分支寫上schedules即可。

3 校驗 .gitlab-ci.yml

GitLab CI 的每個實例都有一個名爲Lint的嵌入式調試工具。 你可以在 GitLab 實例的-/ci/lint下找到該鏈接。

4 配置郵件發送

如果希望在每次構建完成後（或者在僅構建失敗的情況下），想郵件發送給相關開發人員，則可以在 GitLab Settings -> Integrations 中找到Pipelines emails，點擊進去就可以配置郵件發送相關的內容了。

5 GitLab Pages

GitLab Pages是用於託管靜態文件的服務。而pages是一個特殊的job，用於將靜態的內容上傳到GitLab，可用於爲您的網站提供服務。它有特殊的語法，因此必須滿足以下兩個要求：

• 任何靜態內容必須放在public/目錄下
• artifacts必須定義在public/目錄下

下面的這個例子是將所有文件從項目根目錄移動到public/目錄。.public工作流是cp，並且它不會循環複製public/本身。

pages:
  stage: deploy
  script:
  - mkdir .public
  - cp -r * .public
  - mv .public public
  artifacts:
    paths:
    - public
  only:
  - master

更多內容請查看GitLab Pages用戶文檔。

6 跳過 jobs

如果你的commit信息中包含[ci skip]或者[skip ci]，不論大小寫，那麼這個commit將會創建但是 jobs 也會跳過。

---

參考文檔

• 官方文檔地址
• segmentfault yaml配置中文翻譯