前言

延續前兩篇文章，所提到的 cache 和 artifacts 兩個腳本屬性。兩種屬性都有一個特性，就是會將指定的內容存放在特定的位置。但使用上和用途面是完全不同的，接著我們來看一下他們的差異。

Cache vs Artifacts

| 屬性 | 功能描述 |
| --- | --- | --- |
| Cache | 將 Job 運行過程中的檔案以壓縮方式存放在本地 GitLab Runner 中，供給其他 Job 在後續或他次於此運行時，可以依據 key 來找到先前緩存的檔案，其目的為降低持續整合所需的時間 |
| Artifacts | 將 Job 運行過程中的檔案以壓縮方式存放在遠端 GitLab Server 上，供給給同次不同 Stage 間的 Job 可以獲取先前已產生的緩存檔案，其目的為解決持續整合過程間檔案相依的問題 |

使用建議

Cache

由於每次運行腳本時，Job 預設是隨機指定 GitLab Runner 執行，有高機率無法使用先前所準備的檔案，或是在不同台設備上跑完後，都存放了一份 Cache 導致空間的浪費，建議搭配 Tags 可以指定特定標籤的 Executor，如此就能準確命中緩存的檔案實現加速效果。

Artifacts

作者自己在使用 Artifacts 只有遇到兩個問題。

1. 早期 GitLab 8.7 左右的版本，對於 expire_in 的標籤沒有正常的支援，會造成檔案在不知何時刪除，或是根本不刪除的困擾，GitLab 9 之後的版本有對這件事修正。

2. Artifacts 會使用到網路進行傳輸，有機率在伺服器網路平寬不足或伺服器過於忙碌時，導致即便 Retry 數次也失敗的情況，最終造成該次整合測試失敗，建議使用時留意相關的配置。

定期清理

定期清理 Cache 與 Artifacts 是一件重要的事情，尤其是在自建的 GitLab Server 或 Runner 沒有足夠大空間時，這件事情變的尤為重要。

Cache 存放路徑

Artifacts 存放路徑

Artifacts 預設存放在 /home/git/gitlab/shared/artifacts 目錄中，詳情參考連結。

範例

腳本內容

image: docker:stable

stages:
  - build
  - test

job1:
  stage: build
  cache:
    key: "$CI_JOB_NAME-cache"
    paths:
      - cache.txt
  script: 
    - echo "this is cache file" > cache.txt
    - echo "this is artifacts file" > artifacts.txt
    - echo "build, ok"
  artifacts:
    name: "$CI_JOB_NAME-artifacts"
    paths:
      - artifacts.txt
    expire_in: 30 mins

job2:
  stage: test
  script:
    - cat artifacts.txt
    - echo "test, ok"
  dependencies:
    - job1

執行結果

運行第二次的 Pipeline 畫面

運行第二次的 Job1 詳細內容

運行第二次的 Job2 詳細內容

結語

通過範例中的 Job1 詳細內容，可以看到運行第二次時，有獲取到第一次所產生的 Cache。而 Job2 詳細內容中，則可以看到成功獲取到 Job1 所產生的 Artifacts。經過一連串的介紹期望能使讀者在運用到相關功能時，能減少踩雷的機會。

如果嫌 Cache 和 Artifacts 麻煩的讀者，不妨試試存放在遠端的 S3 或其他可以上傳的空間，通過一些命名規則也能自行實現相關的功能，在檔案清理上也會更加的簡潔，缺點大概就是指令會變多，再請自行評估囉。

Reference

• Cache dependencies in GitLab CI/CD | GitLab
• Jobs artifacts administration | GitLab