2022 年 09 月 - 如何撰寫好用的 GitLab CI 設定檔

Q1：為什麼需要 CI

1. 持續性整合：目的加快 code 整合
2. 持續性交付
3. 持續性部署

也就是說，大部分工具原本都是要拿來做持續整合，但以 Jenkins 、Gitlab CI 為例，結果大家都拿來協助自動化處理 xD

Q2：CI 和 Cronjob/Airflow 的差異為何

1. CI 會有一個 workspace 的環境，不受到語言程式的限制
2. CI 會協助做 workspace 管理

Q3：Coutinuous Delivery 和 Coutinuous Deployment 的差異？

1. 持續整合：testing、執行程式
2. 持續交付：送到 user 手上
3. 持續部署：安裝到客戶端

Q4：什麼是 CI/CD 的 pipeline？

1. 意向：工廠的生產線
2. 定義：所有要處理的步驟之總稱
3. gitlab CI pipeline 類似 github action 的 workflow (名詞會不一樣)

Q5：Job / Stage 的差異？

1. stage：規劃時序
2. job：工作單位
3. 也就是說，兩個不同的 job 既可以安排在不同 stage（前後順序），也可以安排在同一個 stage 一起跑。
4. 規劃 pipeline 的時候，要去思考怎麼安排 stage 才會是對自己最有效益的做法
5. job keyword
   • allow_failure

type of 變數（Variable）

• file（解決了 string 換行問題）
• string

cache

• 不同的 project 之間無法共用 cache
• cache policy:
  • pull-push
  • pull
  • push
• cache 可以被放在 S3 上

artifact

• 通常是生成出來之後希望可以被其他人使用的，e.g. test report
• 可以設定路徑、 expire_in
• artifacts:reports
  • 也可以在 pr 上顯示各個 job 完成的結果
  • 看 testing 的結果（after_script)

needs: 描述是否有需要其他 jobs 所生成的 artifacts
dependency：描述 jobs 完成時序的前後關係，eg. 環境
(兩者互斥⬆️)
rules：進階版的 expect，直接寫 if/else 的 condition

github：keep source code
gitlab：支援 devops 的整個流程
catch 不到：放錯路徑
coverage：可以設定，不設定就不會有，很常忘記

def build_docker
    system("docker build -t my-image .")

end

def pipeline
    [
     Thread.new { rubocop_check },
     Thread.new { rspec_test }
    ].map(&:join)
    # Blocking...
    build_docker
    # X
    deploy
end

stages:
 - test
 - build
 - deploy
 
rubocop_check:
  stage: test
  script: ...
  
rspec_test:
 stage: test
 script: ...