GitLab CI 之 CI trigger、API 與 ChatOps

本系列文是從 iT 邦幫忙鐵人賽系列文章搬至 gitlab-book.tw，鐵人賽撰文時 GitLab 仍為 12.x 版本，因此本系列文內容已有部分過期，本次搬移至此後，會視狀況新增一些補註說明。

本系列文是從 iT 邦幫忙鐵人賽系列文章搬至 gitlab-book.tw，鐵人賽撰文時 GitLab 仍為 12.x 版本，因此本系列文內容已有部分過期，本次搬移至此後，會視狀況新增一些補註說明。 鐵人賽原文網址：https://ithelp.ithome.com.tw/articles/10224332）

今天我們一樣要繼續改善 CI/CD Pipeline，不過今天的內容說是改善 Pipeline 並不太正確，應該說我們要來更靈活的利用 CI Service。

GitLab API 與 CI trigger

現在是一個充滿 API 的時代，各家的 Service 多半都有提供 API 讓使用者可以用 GUI 以外的方式來使用 Service，當然 GitLab 也不例外，提供了眾多的 GitLab API 讓 User 可以更便捷的運用 GitLab。

GitLab API 可以做到的事情眾多，從 Create Project 一直到 trigger CI Job 都不成問題，想知道 API 的所有詳細，建議還是直接參閱官方文件會比較快。

這邊就舉兩個與 GitLab CI 有關的範例，介紹一下可以怎麼運用 GitLab API。

Production Deploy

還記得在我們假想情境中 production branch 的 CI/CD Pipeline 嗎？那時我們有一個 when: manual 的 prod-deploy。

prod-deploy:
  stage: prod-deploy
  only:
    - production
  script:
    - ansible-playbook prod-deploy.yml
  when: manual
  environment:
    name: production
    url: https://production.website.com

我們可以直接在 GitLab 的 Web UI 上手動點擊「按鈕」來驅動它。

但這樣每次都要登入 GitLab，然後開啟該 Project 正確的 CI/CD Pipeline 才能找到它。（謎之音：是有多懶？明明就可以在 CI 跑完時送通知與超連結到 Mattermost，直接打開該網頁。）

不如就將它獨立一條 Pipeline 並且改成能夠以 GitLab API 透過 Command line 來驅動它吧！首先將 .gitlab-ci.yml 改成下面的模樣。

stages:
  - prod-deploy

prod-deploy:
  stage: prod-deploy
  only:
    - triggers
  script:
    - ansible-playbook prod-deploy.yml
  environment:
    name: production
    url: https://production.website.com

如此一來這項 CI Job 就可以透過 API 的方式 trigger 執行它。

接著為你的 User 產生使用 API 所需的 access_token。


（User 如果權限足夠，可以用自己的 access token 來 trigger CI Pipeline。）

或者如果你只需要能夠 trigger 特定 pipeline 的權限，那也可以在該 Project 的 Settings > CI/CD > Pipeline triggers 建立一個 Project's triggers，一樣能以 API 的方式 trigger CI Pipeline。


（針對 Project 設置 trigger token，務必要自行保管好。）

總之有了足夠權限的 token，你就可以搭配 token 使用對應的 API。因此你就能夠用 curl 在 Command line 驅動 CI Pipeline 執行 prod-deploy。


（由上圖可以看到，這個 CI Job 是以 trigger 的方式被啟動執行的。）

Rollbacks

第二個範例也跟 deploy 有點關係，就是當 deploy 失敗或遇到異常狀況而必須倒退回前一個版本時會執行的動作——rollbacks。既然 prod-deploy 都可以用 API 去 trigger，同理要將 production 環境 reollbacks 到前一個版本也可以設置同樣的機制交由專人控管。而這個 CI Job 在 .gitlab-ci.yml 中可能會類似下面這樣：

stages:
  - rollback

rollback:
  stage: rollback
  tags:
    - "ansible"
  only:
    - triggers
  script:
    - ansible-playbook rollback.yml -e version=$project_tag

ChatOps

前面談完了 GitLab API，接著來延伸談一下 ChatOps。這裡就不談什麼 ChatOps 的嚴謹定義，或到底要做到什麼程度、多麼厲害才能稱為 ChatOps。艦長個人認為，只要是透過呼叫即時通訊軟體或團隊溝通協作平台上的 ChatBot，由 ChatBot 代勞執行某些自動化腳本就算是一種 ChatOps。

那 ChatOps 又與 GitLab API 或其他 Service 的 API 有什麼關係呢？

在前面我們不是達成了可以用人工自己透過 Command line + curl 的方式來 trigger CI/CD Pipeline。現在我們只是要將「人工」這個介面換成「ChatBot」而已。也就是說，如果你有辦法善用各種 API 完成各式各樣的任務，現在只要改成讓 ChatBot 幫你代勞，類似下圖的流程。


（User 在 Mattermost 上呼叫 ChatBot 去 trigger CI Pipeline 完成 Prod-deploy。）

舉例來說，我們就可以利用 GitLab API 的 create project + ChatBot，達成在 Mattermost 上呼叫 ChatBot 即可完成開新專案的工作。

小結

今天雖然好像在介紹 GitLab API，但其實主要在談的是一些和自動化有關的概念，就如前面提過的，因為眾多服務都有提供 API，因此這個時代可以被自動化的工作越來越多了，而 CI Service 或 ChatBot 的出現，又讓我們有更多的選擇可以用來幫我們代勞執行任務。所以，各位又懶又有生產力的工程師，還不快點建立一群自己的 Bot 或 Worker，一起過著又懶又有生產力的人生吧！

最後要提一下，在 GitLab 未來功能的 feature 中，也有一項是 GitLab ChatOps。只不過還在發展當中，也許未來 GitLab 又會類似當初綁定 Mattermost 那樣，直接挑選某個開源的 ChatBot 綁定在 GitLab 的生態系中，讓 ChatOps 這件事情也變成簡簡單單就能設置完畢。

今天就分享到這裡，鐵人賽我們明天見～

參考資料

← CI/CD Pipeline 之 CI Service 掛掉時該怎麼辦？
GitLab CI 之 Scheduling Pipelines →