在 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 這個關卡。

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

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

系統預設有哪些執行關卡呢？在手冊上可以看到系統在還沒宣告 stages 的時候，即預設有三個關卡，分別是：build、test及deploy 三個。
接著是系統在沒有宣告的狀態下，為我們啟用了一個 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 其他的參數及定義。我是墨嗓(陳佑竹)，期待這系列的文章能夠讓人有些幫助。