GitLab CI持續集成 - .gitlab-ci.yml

在以前的文章中介紹了:

GitLab CI持續集成 - GitLab Runner 安裝與註冊

GitLab CI持續集成-GitLab Runner

配置好環境下一步能夠正式開始使用GitLab CI進行項目集成，這裏以Java項目爲例，使用Gradle作爲項目自動構建工具，使用Gradle工具作代碼質量檢查，詳情參見使用Gradle作Java代碼質量檢查。

.gitlab-ci.yml

Gitlab CI使用YAML文件(.gitlab-ci.yml)來管理項目配置。該文件存放於項目倉庫的根目錄，它定義該項目如何構建。

YAML是一個可讀性高，用來表達數據序列的格式。YAML參考了其餘多種語言，包括:C語言、Python、Perl，並從XML，電子郵件的數據格式中得到靈感。 YAML是"YAML Ain't a Markup Language"(YAML不是一種標記語言)的遞歸縮寫。在開發的這種語言時，YAML的意思實際上是:"Yet Another Markup Language"(還是一種標記語言)，但爲了強調這種語言以數據做爲中心，而不是以標記語言爲重點，而用反向縮略語重命名。 --- 維基百科

.gitlab-ci.yml文件定義了一系列帶有約束說明的任務，這些任務都是以任務名開始要包含script部分，一個.gitlab-ci.yml的例子:

stages:
  - unit-test


UnitTest:
  stage: unit-test
  tags:
    - spring-sample
  script:
    - gradle test
    - gradle jacocoTestReport
    - gradle sonarqube
  when: always

複製代碼

下面詳細解釋下腳本中字段的含義

構建腳本解析

stages定義能夠被調用的階段，默認定義爲build,test和deploy，執行順序：

1. 相同stage的job能夠平行執行。
2. 下一個stage的job會在前一個stage的job成功後開發執行

這裏定義了一個stage：unit-test。 下面的UnitTest是定義的一個任務，這個任務在stage爲unit-test時執行。 tags表示他須要執行的gitlab-runner，這裏在一個tag爲spring-sample的tag中執行。 script表明須要執行的腳本，該例子中執行的腳本包括三步：

1. 運行gradle測試
2. 進行單元測試覆蓋狀況檢查
3. 運行sonarqube進行代碼質量檢查

when定義什麼時候執行任務，能夠是on_success，on_failure，always(每次代碼更新都觸發)或者manual(手動觸發)。

另外，比較經常使用的字段還有: before_script用來定義全部job以前運行的命令，包括部署任務等,能夠是一個數組或者是多行字符串 after_script用來定義全部job以後運行的命令。它必須是一個數組或者多行字符串 例如：

job:
  before_script:
  - execute this instead of global before script
  script:
  - my command
  after_script:
  - execute this after my script
複製代碼

cache用來指定須要緩存的文件或目錄，例如：

job1:
  script: test
  cache:
    paths:
    - binaries/
    - .config
複製代碼

更多字段能夠參考官方文檔。

運行GitLab CI

配置完成以後，當把代碼push到版本庫中時就能夠在CI/CD中看到相關的jobs:

進入詳情能夠看到詳細的項目構建信息，能夠根據產生的日誌跟蹤錯誤緣由，這裏出錯的緣由是在gitlab-ruuner中沒有安裝gradle的環境，安裝完gradle環境以後構建任務運行經過。Ubuntu 安裝 Java JDK & Gradle

引用

YAML: zh.wikipedia.org/wiki/YAML GitLab CI/CD Pipeline Configuration Reference ：docs.gitlab.com/ee/ci/yaml/ 經過 .gitlab-ci.yml配置任務：github.com/Fennay/gitl…