目錄

• 目錄
  • 摘要
  • 如何觸發workflow
    • 觸發不在default branch上的workflow
  • 常用的觸發事件 & filter
    • 自動觸發
    • 手動觸發
  • 在workflow內觸發另一個workflow
    • workflow_run
    • repository_dispatch

摘要

在上一篇我們學到如何使用表達式跟function在workflow中設立條件、處理資料

在這篇我們會來了解一下自動、手動觸發workflow的事件

如何觸發workflow

就像是JS的事件一樣，我們必須自行把事件監聽綁在元素上，或者自行呼叫function，function才會被觸發

常見的workflow觸發事件大致上能分為自動、手動和排程幾種

透過on屬性可以定義觸發事件，且一個workflow可以有多個觸發事件

首先不論是要自動、手動或排程，都用on:定義觸發事件

name: Foo
on:
  # 發PR到main、名稱含有release/的分支時觸發
  pull_request:
    branches:
      - main
      - release/**
    # ignore叫release/bar的分支
    branches-ignore:
      - release/bar

  # 手動觸發、無輸入欄位
  workflow_dispatch:

  # 排程，GMT+8每週一早上9點執行
  schedule:
    - cron: '0 1 * * 1'

觸發不在default branch上的workflow

不過如果你的workflow沒被推到default branch上過(通常是main或master)，而你想要在發PR前試看看這個workflow，

那麼頗不幸的即便有定義workflow_dispatch，仍然無法在Github Actions的頁手動觸發他、使用Github Cli也沒辦法，因為這兩個方法都不會列出不在default branch的workflow

# 列出default branch上可用的workflow，預設會把disable的藏起來
gh workflow list

# 列出default branch上所有workflow
gh workflow list -a

# workflow的name是name: 的值，不是檔名喔
# 以上面的例子來說就是Foo
gh workflow run <workflow的name> --ref <分支名>

如果硬要用指令觸發他，只會噴錯"could not find any workflows named <workflow的name>"

不過仍然可以使用偷吃步定義push: 解決

name: Foo
on:
  pull_request:
    branches:
      - main

  # 略
  push:
   branches:
    - 當下開發用的分支名

之後只要push到遠端就會被觸發了，也可以在Github Actions的頁、使用Github Cli的指令看到它

常用的觸發事件 & filter

使用filter用法跟正規表達式差不多，可以設置條件過濾分支、tag、commit之類的東西，除了常見的**和!，還有*、+、?之類的filter可以用，需要跳脫時字串時用\

在下面的例子中會示範使用當中幾種

另外需要注意的是，GitHub Actions 中，diff 只會處理 前300個變更檔案。如果你使用的filter没有在在前300個找到符合條件的更改，workflow就不會被觸發

自動觸發

• pull_request

  name: Foo
  on:
    # 發PR到所有不叫release/bar的所有分支時觸發
    pull_request:
      branches:
        - !release/bar
  

• push

  on:
  push:
    # 只在push的更動的檔案中有json檔時觸發
    paths:
      - '**.json'
    # 但是不檢查以下這些json
    paths-ignore:
      - .stylelintrc.json
      - .eslintrc.json
      - package.json
  

• issue

  on:
    # 有新的issue時
    issues:
      types:
        - opened
  jobs:
    inform owner of repo:
      # 如果標題包含critical
      if: contains(github.event.issue.title, , 'critical')
  

• issue_comment

  • 名稱有陷阱，你可能會以為只有在issue有留言時才會觸發，但其實PR有留言也會，而discussion的話則用discussion_comment

  on: issue_comment
  
  jobs:
    inform developer of PR:
      # 判斷是否為PR有新留言
      if: ${{ github.event.issue.pull_request }}
  

• release

  

  # 使用Github網頁發布新版本時(上圖黃圈處會多一個新版本)
  on:
    release:
      types: [published]
  

手動觸發

在前面的段落我們已經知道定義了workflow_dispatch可以手動觸發，但事實上不只手動觸發，甚至還可以設置input傳一些資料給workflow

但需要注意的是input上限是10個、65535字元，且最好設置options:避免使用者輸入一些奇怪的內容造成安全上的風險

on:
  workflow_dispatch:
    inputs:
      workspaceName:
        required: true
        default: 'foo'
        options:
          - foo
          - bar
      environment:
        description: 'Environment to run tests against'
        default: 'dev'
        options:
          - dev
          - alpha
          - beta
          - prod

在workflow內觸發另一個workflow

workflow_run

使用workflow_run，並定義types可以控制workflow間執行的順序，分為requested(開跑)、completed(完成)、in_progress(正在跑)

不過這個方法不能超過3層，如果硬要這麼做的話第4層開始就不會觸發 (A → B → C → D可以，超過D後就不行)

另外如果做的事情之間夠獨立的話，透過這種方式拆分workflow也能達到間接複用的效果，至於其他複用方式在之後的篇章會提到

name: (Runtime) Commit Artifacts for Meta WWW and fbsource V2

on:
  # 當名為(Runtime) Build and Test的workflow在main分支上跑完，且成功跑完後
  workflow_run:
    workflows: ["(Runtime) Build and Test"]
    types: [completed]
    branches:
      - main
    conclusion: success

repository_dispatch

repository_dispatch是一個很特別的事件，types完全是自訂的，不過types的名稱最多只能有100字元

它是透過Github API來觸發的，通常用於觸發點發生在Github之外時，至於如何建立repo dispatch event在之後的篇章會提到