.gitlab-ci.yml Gitlab CI 簡單配置

Gitlab

原文發表在個人博客: Level Up

最近離職，一張機票跨越小半個中國，來魔都找了一份喜歡的工做。穩定了就開始繼續寫東西啦 👯‍

畢業實習的時候在公司裏面積極推 Git，考慮到同事的學習成本，在 Gogs 和 Gitlab 之間，我選了 Gogs，不爲別的，只爲原生中文 😂。而後一大段時間，我都是在 Github 和 Gogs 這兩個平臺進行協做的，Gitlab 的大名也不時的在耳邊響起。

如今的公司版本控制用的是 Gitlab，因此藉此機會我也簡單適應了一下，其實和 Github 差不太多，更多的是 Gitlab 提供了一整套的解決方案，其中就包含了 CI/CD。

我仍是比較崇尚那句話的：一切能自動化的工做都應該被自動化掉！

.gitlab-ci.yml

在 Gitlab 官網上有不少關於 gitlab CI 如何搭建的介紹，在此我就很少作介紹了，就是照着代碼敲到命令行執行便可，如今要講的是如何配置一個簡單的 Gitlab CI 配置文件。

.gitlab-ci.yml 這個文件便是 Gitlab CI 的配置文件，你須要將這個文件放到你 repo 的根目錄便可，而後你每次提交， Gitlab 都會自動地去讀取執行該文件的內容，若是你提交了一個新的 .gitlab-ci.yml，那 gitlab CI 會使用你剛提交的那份配置文件進行 CI

下面就貼一份簡單的用於部署前端項目的 .gitlab-ci.yml 文件:

# 這個是我如今項目初期使用的一個配置文件
# 下面我就開始簡單的講一下各個配置的做用
# yml 文件支持註釋，像當前文字這樣，左側以 # 號開頭即爲註釋

# 下面這個是表示，咱們運行 CI 用的鏡像是 kkarczmarczyk/node-yarn:latest
# 由於我司的 CI 任務是選的在 Docker 上運行，因此每次執行 CI 任務的時候，都會新啓動一個 Docker 容器
# 而後在容器中依次執行下面的命令
# 注意：不一樣的 stage 執行前，都會將該容器環境設置爲初始化時的狀態
image: kkarczmarczyk/node-yarn:latest

# 定義全局的緩存策略，如上所說，每一個不一樣的 stage，CI 都會從新啓動一個新的容器，因此咱們以前 stage 中的文件都會消失
# 那在前端開發中，就意味着每一個 stage 都要從新完整裝一次 node_modules，這樣的時間和網絡成本都不低
# 因此咱們選擇將這些文件緩存下來
# 可是，緩存也要講究實效性，例如我在第二次的提交中增長了一個庫，那第二次的 CI 就不能再重複使用上一次的 node_modules 緩存了
# 在 .gitlab-ci.yml 中，咱們經過設置 cache 的 key 來區分不一樣的緩存
cache:
  # 該 Key 的值爲一個系統變量，gitlab 在運行的時候內置了很多的系統變量供使用，下面的配置表示
  # 以每次提交的 ref 號爲 key 來區分不一樣緩存，效果就是同一次提交中的全部 stage 用同一份 cache
  key: ${CI_COMMIT_REF_SLUG}

# 定義 stage，stage 能夠簡單的理解爲「步驟」，會順序執行，若是上一步錯了，那不會繼續執行下一步
# 好比像下面我定義的，第一步先初始化，第二步檢查代碼規範，第三步進行單元測試，第四步構建，第五步就直接將項目部署到服務器
stages:
  - init
  - lint
  - unit_test
  - build
  - deploy

# 這個是某個任務的名稱，你能夠隨意起名
install_packages:
  # 指定該任務所屬的步驟，每到一個步驟，該步驟所對應的全部任務都會並行執行
  stage: init
  # 指定要緩存的文件以及文件夾
  cache:
    # 這個屬性是 gitlab 比較新版本里面加的特性，意思是在這一步，我只上傳這個緩存，我不會拉取該緩存
    policy: push
    # 指定緩存的內容，在下面我緩存了 node_modules 這個文件夾，你還能夠在下面繼續添加文件或者文件夾
    paths:
      - node_modules/
  # 該任務要運行的腳本，順序執行
  # 都是 bash 命令
  # 默認當前目錄就是 repo 的根目錄
  script:
    # 我先列出全部文件的列表，便於 script 出錯後進行調試
    - "ls -la"
    # 設置 yarn 的源，會快一些
    - 'yarn config set registry "https://registry.npm.taobao.org"'
    # 安裝全部依賴，也就是 node_modules
    - "yarn"

# 執行完 init 這個 stage（步驟）後，咱們的 node_modules 目錄就緩存下來了
# 而後咱們就開始執行代碼檢查
lint_code:
  # 對應的步驟是代碼檢查，能夠多個任務指向同一個 stage，這些任務將會被並行執行
  stage: lint
  # 定義緩存
  cache:
    # 下面的配置指示，咱們當前只拉取緩存，不上傳，這樣會節省很多時間
    policy: pull
    # 指定要緩存的文件/文件夾
    paths:
      - node_modules/
  # 該任務要運行的 bash 腳本
  script:
    - "ls -la"
    - "yarn lint"

# 單元測試
unit_test:
  # 隸屬於 單元測試 這個步驟
  stage: unit_test
  # 同 lint_code 任務，拉取緩存，咱們就不用再從新下載 node_modules 了
  cache:
    policy: pull
    paths:
      - node_modules/
  # 執行 bash 命令
  script:
    - "ls -la"
    - "yarn test:unit"

build:
  stage: build
  cache:
    policy: pull
    paths:
      - node_modules/
  # artifacets 是打包你指定的文件或者文件夾，而後你能夠經過 gitlab 的頁面進行下載的
  artifacts:
    # artifacets 的名字
    name: "dist"
    # artifacets 的過時時間，由於這些數據都是直接保存在 Gitlab 機器上的，過於久遠的資源就能夠刪除掉了
    expire_in: 60 mins
    # 制定須要打包的目錄，這裏我把 dist 目錄給打包了，準備發佈到服務器
    paths:
      - dist/
  script:
    - "ls -la"
    - "yarn build"

# 部署任務
deploy:
  stage: deploy
  # 該命令指定只有 master 分支纔可以執行當前任務
  only:
    - master
  # 部署腳本，在下面的代碼中，我用到了不少相似 ${AMAZON_PEM} 的變量，因爲咱們的私鑰、Ip 都算是不宜公開顯示的信息，
  # 因此我用到了 Gitlab 的變量工具，在 repo 的 Setting > CI/CD > Secret variables 中，這些變量值只有項目管理員纔有權限訪問
  script:
    - "ls -la"
    - "ls -Rl dist"
    - 'echo "${AMAZON_PEM}" > amazon.pem'
    - "chmod 600 amazon.pem"
    - "scp -o StrictHostKeyChecking=no -i amazon.pem -r dist/* ${AMAZON_NAME_IP}:/usr/share/nginx/html/"

坑 s

在使用的過程當中，仍是經歷了一些坑的，也記錄下來

• 公司的 Gitlab 估計是版本問題，cache 基本是失效的，因此無奈，我直接添加了一個 before_script 來在每一個 jobs 執行前都完整安裝一次 node_modules
• 將服務器私鑰保存到 Gitlab 的 CI 變量中後，本想經過 echo ${AMAZON_PEM} > amazon.pem，把私鑰存儲爲文件使用，結果發現 echo 出來的文本沒有了換行，最終解決辦法是 echo "${AMAZON_PEM}" > amazon.pem（就只須要加兩個引號）

原文發表在個人博客: Level Up