GitLab CI介紹——入門篇

本文將會對Gitlab CI進行簡要介紹，包括Gitlab Runner，Gitlab CI中的相關概念以及.gitlab-ci.yml的經常使用配置。

那麼，GitLab CI 是什麼？

GitLab CI 是GitLab內置的進行持續集成的工具，只須要在倉庫根目錄下建立.gitlab-ci.yml 文件，並配置GitLab Runner；每次提交的時候，gitlab將自動識別到.gitlab-ci.yml文件，而且使用Gitlab Runner執行該腳本。

Gitlab Runner

簡介

GitLab-Runner就是一個用來執行.gitlab-ci.yml 腳本的工具。能夠理解成，Runner就像認真工做的工人，GitLab-CI就是管理工人的中心，全部工人都要在GitLab-CI裏面註冊，而且代表本身是爲哪一個項目服務。當相應的項目發生變化時，GitLab-CI就會通知相應的工人執行對應的腳本。

Runner類型

GitLab-Runner能夠分類兩種類型：Shared Runner（共享型）和Specific Runner（指定型）。

• Shared Runner：全部工程都可以用的，且只有系統管理員可以建立。
• Specific Runner：只有特定的項目可使用。

Runner搭建

▍1. Runner 安裝

以Linux爲例：

# 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

其餘系統請參考官網文檔: https://docs.gitlab.com/runne...

▍2. 獲取Runner註冊Token

安裝好Runner以後，須要向Gitlab進行註冊，註冊Runner須要GitLab-CI的url和token。可根據需求註冊選擇所需類型Runner。

獲取Shared Runner註冊Token：
使用管理員用戶登陸，進入Admin Area->OverView->Runners界面。

獲取Specific Runner註冊Token：
進行項目倉庫->settings->CI/CD界面

▍3. 註冊Runner

執行gitlab-ci-multi-runner register命令進行Runner註冊，期間會用到前期獲取的url及token；註冊完成以後，GitLab-CI就會多出一條Runner記錄：

更多系統註冊，請參考閱讀官方文檔：https://docs.gitlab.com/runne...

相關概念

▍管道（pipeline）

每一個推送到 Gitlab 的提交都會產生一個與該提交關聯的管道(pipeline)，若一次推送包含了多個提交，則管道與最後那個提交相關聯，管道(pipeline)就是一個分紅不一樣階段(stage)的做業(job)的集合。

▍階段（Stage）

階段是對批量的做業的一個邏輯上的劃分，每一個 GitLab CI/CD 都必須包含至少一個 Stage。多個 Stage 是按照順序執行的，若是其中任何一個 Stage 失敗，則後續的 Stage 不會被執行，整個 CI 過程被認爲失敗。

以圖中所示爲例，整個 CI 環節包含三個 Stage：build、test 和deploy。

• build 被首先執行。若是發生錯誤，本次 CI 馬上失敗；
• test 在 build 成功執行完畢後執行。若是發生錯誤，本次 CI 馬上失敗；
• deploy 在 test 成功執行完畢後執行。若是發生錯誤，本次 CI 失敗。

下圖是Gitlab對階段和階段狀態的展現：

▍做業（Job）

做業就是運行器(Runner)要執行的指令集合，Job 能夠被關聯到一個 Stage。當一個 Stage 執行的時候，與其關聯的全部 Job 都會被執行。在有足夠運行器的前提下,同一階段的全部做業會併發執行。做業狀態與階段狀態是同樣的，實際上，階段的狀態就是繼承自做業的。

做業必須包含script（由Runner執行的shell腳本），隨着項目愈來愈大，Job 愈來愈多，Job 中包含的重複邏輯可能會讓配置文件臃腫不堪。.gitlab-ci.yml 中提供了 before_script 和 after_script 兩個全局配置項。這兩個配置項在全部 Job 的 script 執行前和執行後調用。

Job 的執行過程當中每每會產生一些數據，默認狀況下 GitLab Runner 會保存 Job 生成的這些數據，而後在下一個 Job 執行以前（甚至不侷限於當次 CI/CD）將這些數據恢復。這樣即使是不一樣的 Job 運行在不一樣的 Runner 上，它也能看到彼今生成的數據。

在瞭解了 Job 配置的 script、before_script、after_script 和 cache 之後，能夠將整個 Job 的執行流程用一張圖歸納：

建立.gitlab-ci.yml 文件

什麼是.gitlab-ci.yml文件

從7.12版本開始，GitLab CI使用YAML文件(.gitlab-ci.yml)來管理項目配置。該文件存放於項目倉庫的根目錄，而且包含了你的項目如何被編譯的描述語句。YAML文件使用一系列約束敘述定義了Job啓動時所要作的事情。

Job

Job是.gitlab-ci.yml文件中最基本的元素，由一系列參數定義了任務啓動時所要作的事情，用戶能夠建立任意個任務；每一個任務必須有一個獨一無二的名字，但有一些保留keywords不能用於Job名稱，image，services，stages，types，before_script，after_script，variables，cache。

Job被定義爲頂級元素，而且至少包括一條script語句，若是一個 Job 沒有顯式地關聯某個 Stage，則會被默認關聯到 test Stage。

示例：

job1:
# 關聯到bulid階段
stage: build
# 所需執行的腳本
script:
- execute-script-for-job1

參數詳情

下面是關於配置CI/CD管道的經常使用參數詳細說明。

▍stages

用於定義全部做業(job)可使用的全局階段，gitlab-ci.yml容許靈活定義多個階段，stages元素的順序定義了做業執行的順序。Job關聯的stage名相同時，該多個Job將並行執行（在擁有足夠Runner狀況下）。下一個階段的job將會在前一個階段的job都完成的狀況下執行。

若是文件中沒有定義 stages，那麼則默認包含 build、test 和 deploy 三個 stage。Stage 中並不能直接配置任何具體的執行邏輯，具體的執行邏輯應該在 Job 中配置。

示例：

stages:
  - build
  - test
  - deploy

▍stage

階段是根據每一個Job定義的，而且依賴於全局定義的階段。它容許將做業(Job)分組到不一樣的階段。

示例：

stages:
  - build
  - test
  - deploy

job 1:
  stage: build
  script: make build dependencies

job 2:
  stage: build
  script: make build artifacts

job 3:
  stage: test
  script: make test

job 4:
  stage: deploy
  script: make deploy

▍script

script是一段由Runner執行的shell腳本。

示例：

job:
  script: "bundle exec rspec"

這個參數也可使用數組包涵好幾條命令：

job:
  script:
    - uname -a
    - bundle exec rspec

有些時候，script命令須要被單引號或者雙引號所包裹。舉個例子，命令中包涵冒號的時候，該命令須要被引號所包裹，這樣YAML解析器才知道該命令語句不是「key: value」語法的一部分。當命令中包涵如下字符時須要注意打引號:: { } [ ] , & * #? | - < > = ! % @ `

▍image and services

這兩個選項容許開發者指定任務運行時所需的自定義的docker鏡像和服務。

示例：

#爲每一個做業定義不一樣的映像和服務
test:2.1:
  image: ruby:2.1
  services:
  - postgres:9.3
  script:
  - bundle exec rake spec

test:2.2:
  image: ruby:2.2
  services:
  - postgres:9.4
  script:
  - bundle exec rake spec

▍before_script和after_script

before_script是用於定義一些在全部任務執行前所需執行的命令, 包括部署工做，能夠接受一個數組或者多行字符串。after_script用於定義全部job執行事後須要執行的命令，能夠接受一個數組或者多行字符串。

示例：

#定義全局 before_script:
default:
  before_script:
    - global before script
#覆蓋全局before_script
job:
  before_script:
    - execute this instead of global before script
  script:
    - my command
  after_script:
    - execute this after my script

▍only and except

• only和except兩個參數說明了job何時將會被建立：
• only定義了job須要執行的所在分支或者標籤
• except定義了job不會執行的所在分支或者標籤

如下是這兩個參數的幾條用法規則：

• only和except若是都存在在一個job聲明中，則所需引用將會被only和except所定義的分支過濾
• only和except容許使用正則
• only和except容許使用指定倉庫地址，可是不forks倉庫

此外，only和except容許使用如下一些特殊關鍵字：

值	描述
branches	當一個分支被push上來
tags	當一個打了tag的分支被push上來
api	當一個pipline被piplines api所觸發調起，詳見piplines api（https://docs.gitlab.com/ce/ap...）
external	當使用了GitLab之外的CI服務
pipelines	針對多項目觸發器而言，當使用CI_JOB_TOKEN並使用gitlab所提供的api建立多個pipelines的時候
pushes	當pipeline被用戶的git push操做所觸發的時候
schedules	針對預約好的pipline而言（每日構建一類~，具體請看https://docs.gitlab.com/ce/us...）
triggers	用token建立piplines的時候
web	在GitLab頁面上Pipelines標籤頁下，你按了run pipline的時候

下面的例子，job將會只在issue-開頭的refs下執行，反之則其餘全部分支被跳過：

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

更多配置詳情，請參考官網文檔：
https://docs.gitlab.com/ee/ci...

驗證.gitlab-ci.yml

GitLab CI的每一個實例都有一個名爲Lint的嵌入式調試工具，它能夠驗證.gitlab-ci.yml文件的內容，進入項目倉庫->CI/CD->CI Lint，示例以下：

參考文檔：

• https://segmentfault.com/a/11...
• https://docs.gitlab.com/ce/ci/
• https://www.jianshu.com/p/306...
• https://linux.cn/article-9214...

關於豬齒魚

Choerodon 豬齒魚做爲開源多雲應用敏捷全鏈路技術平臺，是基於開源技術Kubernetes，Istio，knative，Gitlab，Spring Cloud來實現本地和雲端環境的集成，實現企業多雲/混合雲應用環境的一致性。平臺經過提供精益敏捷、持續交付、容器環境、微服務、DevOps等能力來幫助組織團隊來完成軟件的生命週期管理，從而更快、更頻繁地交付更穩定的軟件。

更加詳細的內容，請參閱Release Notes和官網。

你們也能夠經過如下社區途徑瞭解豬齒魚的最新動態、產品特性，以及參與社區貢獻：

• 官網：http://choerodon.io
• 論壇：http://forum.choerodon.io
• Github：https://github.com/choerodon

歡迎加入Choerodon豬齒魚社區，共同爲企業數字化服務打造一個開放的生態平臺。

本篇文章出自 Choerodon豬齒魚社區史常萍。