使用觸發程序來控制工作流程執行的時機

5 分鐘

您現在有一個運作中的工作流程，可將您的 Bicep 檔案部署到 Azure 環境。但是，每當您變更該檔案，都必須手動執行工作流程。在此單元中，您將學習如何在每次變更 Bicep 程式碼後，即觸發工作流程自動執行。

注意

本單元中的命令僅用於示範概念。請先不要執行命令。您很快就會在此練習所學到的內容。

什麼是工作流程觸發程序？

工作流程觸發程序是一種條件，一旦符合，即會根據您建立的規則自動執行工作流程。您可以設定這些觸發程序依排程間隔執行工作流程。您也可以設定觸發程序，在存放庫中的檔案變更時執行工作流程。您可以選擇第二個選項，因為每當他人變更您的程式碼時，執行所有的測試和部署步驟會是個好主意。

如果您未使用自動觸發程序，則他人可能會對 Bicep 檔案進行變更，甚至認可它並將之推送至存放庫，但如果他們忘記執行工作流程，Bicep 檔案中的資源定義與部署至 Azure 環境的資源之間會有差異。假設已完成更多認可和推送，但尚未部署。如果有人在 Bicep 檔案的其中一個變更中造成錯誤或設定錯誤，可能很難立刻在稍後部署的多個認可之間追蹤到錯誤。一段時間之後，您將無法信任 Bicep 程式碼能真正代表您的基礎結構，而且其值已遭侵蝕。

當將工作流程設定為每次更新檔案後都會執行時，工作流程就會在您推送變更後開始執行。您可以立即獲得變更有效性的意見反應，並確定實際執行環境永遠保持在最新狀態。

推送事件觸發程序

常見的觸發程序類型是「推送事件觸發程序」，也稱為「持續整合觸發程序」或「CI 觸發程序」。當您使用推送事件觸發程序時，只要變更特定分支，就會執行工作流程。如果您認可某個變更並將其推送至不同的分支，則不會觸發執行工作流程。透過此程式碼，針對您的預設或主要分支使用此類型的觸發程序，是相當常見的作法：

on:
  push:
    branches:
      - main

在變更多個分支時觸發

您可以設定觸發程序，針對特定分支或分支集合執行工作流程。例如，假設所建立的「版本分支」包含您將為專案特定版本部署的程式碼。您可以使用類似 release/v1、release/v2 的分支名稱。您希望名稱開頭為 release/ 的分支只要程式碼有變更，就執行工作流程。您也可以使用 ** 萬用字元：

on:
  push:
    branches:
      - main
      - 'release/**'

您也可以排除特定分支。假設您要與小組成員合作處理專案。您的同事建立了「功能分支」，要在 Bicep 檔案中嘗試其想法。所有功能分支都使用類似 feature/add-database、feature/improve-performance 的名稱。您想要對所有分支自動執行工作流程，但您同事建立的功能分支除外。使用 exclude 屬性，您可確保功能分支的變更不會自動觸發工作流程：

on:
  push:
    branches-ignore:
      - 'feature/**'

注意

您可以使用 ! 字元來排除特定分支。假設您想要針對您的主分支和所有發行分支 (Alpha 版本除外) 觸發工作流程。您可以使用 ! 字元來表示：

on:
  push:
    branches:
      - main
      - 'release/**'
      - '!release/**-alpha'

您無法在同一個觸發程序中同時使用 branches 與 branches-ignore，因此 ! 字元可讓您彈性地控制觸發程序的行為。

路徑篩選

您的存放庫中有時會有與部署無關的檔案。例如，您的存放庫中可能有一個包含 Bicep 程式碼的 deploy 資料夾，以及另一個包含文件檔案的 docs 子資料夾。您希望只要有人變更 [部署] 資料夾中的任何 Bicep 檔案就會觸發工作流程，但您不想要因為有人僅對文件檔案進行變更而觸發工作流程。若要設定觸發程序以回應存放庫中特定資料夾的變更，您可以使用「路徑篩選」：

on:
  push:
    paths:
      - 'deploy/**'
      - '!deploy/docs/**'

如果有人認可了只更新文件檔的變更，就不會執行管線。但如果有人變更了 Bicep 檔案，或在變更文件檔案之外還變更了 Bicep 檔案，則觸發程序就會執行工作流程。

注意

您也可以使用 paths-ignore，其運作方式類似 branches-ignore 關鍵字。不過，您無法在同一個觸發程序中同時使用 paths 與 paths-ignore。

排程工作流程自動執行

您可以依照設定的排程執行工作流程，而不是為回應檔案變更而執行。例如，您可以執行 Bicep 程式碼的夜間版本，或在每天早上自動部署測試環境。使用 schedule 關鍵字，並使用 cron 運算式來設定頻率：

on:
  schedule:
    - cron: '0 0 * * *'

注意

「Cron 運算式」是一串經過特殊格式化的字元，可指定某件事發生的頻率。在本範例中，0 0 * * * 表示「在 UTC 時間每天午夜執行」。

在 YAML 檔案中，您需要在包含 * 字元的字串 (例如 cron 運算式) 前後加上引號。

排程事件一律會在您存放庫的預設分支中執行您的工作流程。

使用多個觸發程序

您可以合併多個觸發程序和排程，如下列範例所示：

on:
  push:
    branches:
      - main
  schedule:
    - cron: '0 0 * * *'

當您在相同工作流程中建立分支觸發程序「和」排程觸發程序時，工作流程會在兩種情況下執行：觸發程序所設定分支的檔案每次發生變更時，「以及」您設定的排程。在此範例中，工作流程會在 UTC 時間每天午夜執行，以及在每當變更推送至「主」分支時執行。

提示

為每個工作流程設定觸發程序是良好的做法。如果您沒有設定觸發程序，則根據預設，任何分支的任何檔案只要發生變更，工作流程就會自動執行，而這通常不是您想要的結果。

Webhook 觸發程序

GitHub 也會提供 Webhook 事件，此事件會在您存放庫中發生特定事件時自動執行。這些事件包括有人建立分支、GitHub 問題有更新，或提取要求有變更。一般而言，這些事件不需要執行您的 Bicep 部署工作流程，但您可以改為執行其他自動化。

並行控制

根據預設，GitHub Actions 允許同時執行多個工作流程的執行個體。若您在短時間內對分支做出多項認可，或您先前的執行流程，未能在下一次的排程觸發前完成，就可能會發生這種情況。

在某些情況下，同時執行多個工作流程並不是問題。然而，當您以部署工作流程進行作業時，若想確保您的工作流程執行不會以超估您預期的方式覆寫 Azure 資源或設定，可能不太容易。

若要避免發生這些問題，您可以套用並行控制。使用 concurrency 關鍵字，然後指定在工作流程所有執行項目中一致的字串。這通常是硬式編碼字串，如下列範例所示:

concurrency: MyWorkflow

GitHub Actions 接著會確保其等待任何作用中的工作流程執行完成，然後再開始新的執行。