目錄

• 目錄
  • 摘要
  • workflow 的組成
    • job & step
  • action
  • runner

摘要

在上一篇我們學到了如何用YAML的block style、flow style，以及YAML的優點

在這篇我們會來了解一下workflow大致的架構

workflow 的組成

-- workflow
    ├── job
    │   ├── step
    │   └── step
    │
    └── job
      └── step

寫workflow是為了叫 Github Actions提供的runner幫你在某些時候，自動做一些有固定流程、順序，而且因為常常重複，所以希望他幫你處理的事情

我們可以用英文的5W1H來記住workflow的基本結構

Where: Github Actions
Who: runner
Why: 自動執行更有效率，或者單純是懶得每次都自己處理

// 以下是你要寫進yml檔裡的
// yml檔相當於要給runner看的便條紙，才會知道他在何時幫你做什麼
When: 某些時機，透過on定義
What: 具有固定流程的事，透過name給這整件工作一個名稱，透過jobs定義大的事項，steps定義事項的步驟。一個 `workflow 由幾個 job 組成`，一個 `job 又由幾個 step 組成`
How: 事情的細節，透過run定義執行的內容，use定義使用到的action

此外workflow 可以被另一個 workflow 引用，這是一種複用的方式，之後的篇章會介紹

job & step

job 會在同個 VM runner 內被平行、序列執行，它可以用 shell script、shell command 或者 action

job 預設是沒有依賴的，如果有多個runner就可以平行執行複數個job

你也可以自行設定它們間的依賴關係。如果 job 依賴於其他 job，那它會等到依賴的 job 完成才開始跑，這就是序列執行

step 會被依序執行，並且它們之間會有所依賴，所以可以將某個 step 內的資料傳給另一個 step

action

action 是一種 Github Actions 上的一種將一連串常用的複雜的動作包裝起來的應用

在Github Marketplace可以找到不少其他開發者製作好的 action

如果有需要的話也可以開一個新repo放action並release，這就是自定義Action

runner

runner是執行 workflow 的 server

每個 runner 一次只能跑一個 job，正在排隊的workflow會顯示"Queued"

Github Actions 和 jenkins 有個不同的地方，你不需要在 workflow 內手動清除快取，因為 workflow 每次執行都會在一個乾淨的 runner