GitHub Actions workflow_dispatch 的 boolean 為何要用 inputs context

定義一個手動部署開關#

1
name: Deploy
2

3
on:
4
  workflow_dispatch:
5
    inputs:
6
      deploy_production:
7
        description: Deploy to production
8
        required: true
9
        type: boolean
10
        default: false
11
      environment:
12
        description: Target environment
13
        required: true
14
        type: choice
15
        options:
16
          - staging
17
          - production
18

19
jobs:
20
  deploy:
21
    runs-on: ubuntu-latest
22
    if: ${{ inputs.deploy_production }}
23
    steps:
24
      - run: ./scripts/deploy-production.sh

inputs.deploy_production 在這裡是 boolean，因此未勾選時 job 不會執行。choice 則解析為字串，適合拿來選 environment，但不應被誤當作多個 checkbox 的替代品。

為何字串會讓條件式難讀#

事件 payload 裡也能讀到 github.event.inputs.deploy_production，但它是字串。若一定要使用它，必須明確比較：

1
if: ${{ github.event.inputs.deploy_production == 'true' }}

這不是說 event context 錯了；它適合用於記錄原始事件或與其他 payload 欄位一起處理。問題出在把字串欄位拿去寫「是否執行」的條件，讀者很難一眼看出型別，也容易在重構時做出不對稱的比較。

把手動輸入和部署保護分開#

checkbox 只是操作者的意圖，不是 production 的授權控制。手動 workflow 還應搭配 environment protection、最小化 GITHUB_TOKEN permissions 與部署前驗證。可把流程拆成兩層：

例如不要因為有人勾選 deploy_production，就讓同一個 job 自動擁有所有 repository 或雲端權限。把 deployment job 指向受保護的 environment: production，再為它明確給出需要的 scopes。

發布前的最小測試#

對這種 workflow，我會至少手動跑兩次：一次不勾 production 開關，確認 deploy job 被略過；另一次在受控環境勾選，確認 environment approval、secret 與輸出符合預期。若 workflow 檔不在 default branch，GitHub 也不會讓 workflow_dispatch 觸發可用，這是另一個常被誤認成 YAML 錯誤的前置條件。

若你的手動 workflow 同時使用 cache，請別把輸入參數當成 cache 信任來源；可接著看 GitHub Actions cache 的 restore-keys 安全邊界。

參考資料：

GitHub Docs：Workflow syntax — workflow_dispatch inputs

GitHub Docs：Manually running a workflow