iT邦幫忙

第 12 屆 iThome 鐵人賽

DAY 3
1
DevOps

用 GitLab CI 玩轉自動化測試與佈署系列 第 3

Day03 - GitLab CI 的設定檔有哪些結構?談最基本的 .gitlab-ci.yml

  • 分享至 

  • xImage
  •  

在 Day 02 談到 GitLab Server、GitLab CI、Runner Server 及其 GitLab Runner 彼此之間的關係,今天要繼續往下談這四者間負責定義工作流、關卡及工作的 「gitlab-ci.yml」檔。那麼,一個 gitlab-ci.yml 基本應該要有哪些元素呢?

最基本的 .gitlab-ci.yml

一個最基本有定義工作的 .gitlab-ci.yml 最基本必須要有:

  1. 工作名稱,如下圖,即 script 中第一行 job-name 的部分
  2. 宣告 script 並且至少包含一行的執行工作
job-name:
  script:
	- echo 'hello gitlab-ci' 

如上工作檔案定義,在執行的時候,最終會在畫面中顯示「hello gitlab-ci」的字樣,其執行實際結果可以在這個工作中看到。

工作執行內容

如上圖,畫面中即為實際執行結果的畫面。畫面中又顯示了哪些資訊呢?

  • line 1: Running with gitlab-runner 13.4.0-rc1 (fd488787)

    表示執行這個工作的 runner 版本及版本對應的 hash code,以這次的執行結果來說 runner 版本為 13.4.0-rc1 而 hash code 為後方括弧中的 fd488787

  • line 2: on docker-auto-scale 72989761

    表示這個 runner 所執行的主機、環境及這個 runner 的唯一識別用 hash code。
    line 1 及 line 2 所提供的資訊有時候對於除錯上有莫大的幫助,像是有些失敗的工作在「retry」之後就正常了,這時候就可以聯想到,可能是 runner 的環境可能有異常。透過 line 1 以及 line 2 的資訊,就可以找到執行有誤的環境。

  • line 3-6: Preparing the "docker+machine" executor

    這部分是在正式執行 script 的內容前的執行環境配置動作。如執行內容 gitlab 預設會啟用一個 docker+machine 的 runner executor,其一開始會預設以一個 ruby:2.5 的 docker image 為執行環境,而後即是 pull 該 docker image 的過程。執得注意的是如果使用是 gitlab.com 官方的免費 share runner,這段 pull image 的時間也是計算在內的,因此使用的 docker image 自是越瘦越好,減少 pull 的時間

  • line 8-9: Preparing environment

    環境啟動後的配置,以這邊顯示的訊息來說,說明了這個 runner 是經由什麼 runner server 執行的。

  • line 11-17: Getting source from Git repository

    在這個程序中,主要是從 GIT Repo 中取得原始碼,包含 repo 本體及 git submodules 的內容,在畫面中還顯示了他只取得最後 50 個 commit 的內容;在大型專案中很可能有數萬個 commit,如果完整的將 git repo 都 fetch 下來,那會造成增加不必要的 repo commit 處理,因此系統預設僅取最後的 50 個 commit,當然只取幾個 commit 這部分是可以設定的。

  • line 19-23: Executing ”step_script” stage of the job script_

    最後,執行這個 job 所定義的工作內容,如 line 20,顯示了正在echo 'hello gitlab-ci' 因此在畫面的下一行 line 21 則顯示了印出來的結果「hello gitlab-ci」,執行順利完成後,在 line 23 行顯示 Job succeeded。

以上就是基於所謂最基本的 .gitlab-ci.yml 的執行過程內容說明,但這基本的內容只是表面的那三行描述而已嗎?看起來應該是不止,還包含了一些預設值在,那那些預設又分別是什麼呢?

一個最基本的 .gitlab-ci.yml 全貌是?

從上面對於工作的描述中可以發現,短短的三行其實包含了許多的系統預設值,其中可以發現它缺少了我們在 Day02 常常提到的關卡 Stage,那它到底在什麼樣的關卡執行呢?從下圖執行結果中,可以看到,他的 stage 定義是屬於 test 這個關卡。

插入執行關卡 02

因此這最簡單的 .gitlab-ci.yml 至少長這樣:

job-name:
  stage: test
  script:
    - echo 'hello gitlab-ci' 

系統預設有哪些執行關卡呢?在手冊上可以看到系統在還沒宣告 stages 的時候,即預設有三個關卡,分別是:buildtestdeploy 三個。
接著是系統在沒有宣告的狀態下,為我們啟用了一個 runner,一個配置在 docker+machine executor 環境的 runner 這部分,且載入了 runner 本身預設的 docker image ruby:2.5 (預設載入什麼 image 定義在 runner server 的 runner 上)。

job-name:
  image: ruby:2.5
  stage: test
  script:
    - echo 'hello gitlab-ci'

因此,如果要換比較小的或其他的 image ,就可以透過 image 這個參數來的名稱來調整。接下來關於 .gitlab-ci.yml 還有很多部分,但這基本的 Script 即可以做很多事情,像是執行原始碼中的單元測試等都可以透過這基本的 .gitlab-ci.yml 來完成。

接下來在明天,我們將談談 .gitlab-ci.yml 其他的參數及定義。我是墨嗓(陳佑竹),期待這系列的文章能夠讓人有些幫助。


上一篇
Day02 - GitLab CI 是怎麼運作的?談 GitLab 的基本結構
下一篇
Day04 - GitLab CI 設計出自己的工作流程 - 流水線分析建立 .gitlab-ci.yml 概述
系列文
用 GitLab CI 玩轉自動化測試與佈署31
圖片
  直播研討會
圖片
{{ item.channelVendor }} {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言