Azure Devops 依次運行兩個版本

Question

我們有 Azure DevOps 設置。 現在我們的項目將構建兩次。

一次是在 YAML 文件中的 Pull Request Checkin 期間，另一次是由於構建設置（下圖）。

這會觸發兩次構建，並導致我們的構建時間加倍。 我們的 DevOps 團隊提到這是常規做法。 為什么 Azure Devops 不只觸發一個構建，或者兩個構建的實踐更安全？

Answer 1

從功能上講，這兩個版本可能並不總是相同的。

假設您有以下示例。 大寫字母是提交，小寫字母是潛在的提交。

  e e'
 /   \
|  |   D
C  |   B 
 \ |  /
   A

這表明，兩個分支來自 A 提交（主分支）。 每個功能分支都有一個為每個分支創建的 PR。 一個分支在 e 提交上構建，另一個分支在 e' 提交上構建。 Azure DevOps 無法確定首先合並哪個 PR。

一旦你合並了兩個 PR，你最終會在 master 中得到一個以前沒有構建過的新提交。 這是描述here

   F
   E \
 / |   D
C  |   B 
 \ |  /
   A

如果您想消除在 master 上構建的需要，您可以將構建過期時間設置為Immediately when branch name is updated

Answer 2

為什么 Azure Devops 不只觸發一個構建，或者兩個構建的實踐更安全？

據我所知，這是 Azure Devops 的預期工作流程。

由於構建設置

這是拉取請求觸發器。

此觸發器發生在 Pull Request 的過程中，PR 觸發器旨在在創建 PR 時運行。

這個觸發器相當於一個驗證步驟，文件並沒有真正提交到目標分支（Pre-merged to Targer Branch）。

您可以檢查構建結果以確定源分支代碼是否有效。

例如：

如果拉取請求觸發器失敗，您可以拒絕拉取請求。 不影響目標分支，目標分支保持原狀

在 YAML 文件中拉取請求簽入

這可能是CI 觸發器。

這個觸發器會在拉取請求完成時發生。

在這種情況下，目標分支已更改。 目標分支的變化觸發 CI 觸發器。 這可以再次檢查代碼是否有效。

工作流程總結：

創建 Pull Request -> Pull Request Trigger（Pre-merged and firest check）->Complete Pull Request -> CI trigger（完成分支合並和第二次檢查）。

順便說一句，如果你想排除一些文件，這樣它們就不會觸發 Pull Request Trigger，你可以添加一個路徑過濾器。

例如：