GitHub Actions concurrency 怎麼設：部署工作流避免互相取消的 queue 選擇

只保留最新提交：預覽環境的設定#

同一 concurrency group 預設最多保留一個 pending run；再來一個 run 時，原本等待中的 run 會被取消並由新的取代。對每次 push 都重建的 preview，這正好避免舊 commit 排隊後才發布。

1
name: Preview
2

3
on:
4
  push:
5
    branches: [main]
6

7
concurrency:
8
  group: preview-${{ github.ref }}
9
  cancel-in-progress: true
10

11
jobs:
12
  deploy:
13
    runs-on: ubuntu-latest
14
    steps:
15
      - run: ./scripts/deploy-preview.sh

cancel-in-progress: true 不只替換等待中的 run，也會取消同組正在執行的 run。這適合可安全重跑、且部署程序能處理中斷的 preview；若腳本會做不可逆的 migration，就不要照抄這個設定。

每個版本都要跑：production 用 queue: max#

需要保留每次 release 的順序時，使用 queue: max 讓同組最多排隊 100 個 run。它不能與 cancel-in-progress: true 同時使用，GitHub 會把這個組合視為 workflow 驗證錯誤。

1
concurrency:
2
  group: production-deploy
3
  queue: max

這不會替你的部署做版本鎖定或 rollback。它只是保證同組不會同時執行；資料庫 migration、人工核准與部署健康檢查仍要在 job 裡處理。

group 名稱要包含工作流與環境#

group 名稱不區分大小寫，而且不同 workflow 若用了相同名稱，也會互相影響。建議將 workflow 與目標環境都放進 key：

1
concurrency:
2
  group: ${{ github.workflow }}-production
3
  queue: max

若 workflow 同時處理 pull_request 與 push，像 github.head_ref 這種只在 pull request 存在的欄位必須提供 fallback，否則 group expression 可能無法組成有效名稱。

提交前的檢查清單#

1. 寫下被取消的 run 是否可以安全重跑或中斷。
2. 確認 group 不會跨 workflow、跨 staging／production 意外共用。
3. production 若不能遺失發布，改用 queue: max，並移除 cancel-in-progress。
4. 以連續兩次 push 在非正式環境測試 Actions 頁面的 pending 與 cancel 結果。

如果 workflow 還涉及不可信的 fork PR，先完成 GitHub Actions pull_request_target 的 checkout 保護；concurrency 只能序列化執行，不能降低權限風險。

參考資料：

GitHub Docs：Control workflow concurrency

GitHub Docs：Concurrency 概念