已處理來自開發人員社群的多個要求

為了回應您的意見反應,我們已設定您在開發人員社群中要求的多個功能優先順序。 在 Pipelines 中,我們新增了 YAML 運算式中字串分割函式的支援。 此外,我們現在可讓您停用顯示管線執行的最後一個認可訊息。 在「傳遞計畫」中,我們已將小組限制從 15 增加到 20。

如需詳細資訊,請參閱版本資訊。

Azure Boards

Azure Pipelines

Azure Boards

將傳遞計畫小組限制從 15 增加到 20

傳遞計畫可讓您檢視整個組織的多個待辦專案和多個小組。 先前,您可以檢視 15 個小組待辦專案,包括來自不同專案的積存專案和小組混合。 在此短期衝刺中,我們會將上限從 15 增加到 20。

我們已修正報告工作專案連結取得 API 中的錯誤,以傳回連結類型的正確 remoteUrl 值 System.LinkTypes.Remote.Related 。 在此修正之前,我們傳回錯誤的組織名稱和遺漏的專案識別碼。

新增面板中樞錯誤修正

在此短期衝刺中,我們已修正 New Boards Hub 的多個 Bug。 您可以在 New Boards Hub、Sprint 209 更新部落格文章中看到 Bug 修正清單。

Azure Pipelines

停用顯示管線執行的最後一個認可訊息

先前,顯示管線執行時,用來顯示最後一個認可訊息的 Pipelines UI。

上次認可訊息的範例

例如,當您的 YAML 管線程式碼位於存放庫,與保存所建置程式碼的存放庫不同時,此訊息可能會造成混淆。 我們聽到您來自開發人員社群的意見反應要求我們啟用/停用將最新的認可訊息附加至每個管線執行的標題。

透過此更新,我們已新增名為 appendCommitMessageToRunName 的新 YAML 屬性,讓您確實這麼做。 根據預設,屬性會設定為 true 。 當您將它設定為 false 時,管線執行只會顯示 BuildNumber

具有組建編號的管線執行範例

使用最後一個認可訊息執行的管線執行範例

管線執行 Rest API 中的已耗用資源和範本參數

擴充 管線執行 REST API 現在會傳回管線執行所使用的更多成品類型,以及用來觸發該執行的參數。 我們已增強 API,以傳回 container 管線執行中使用的 和 pipeline 資源和範本參數。 例如,您現在可以撰寫合規性檢查,以評估管線所使用的存放庫、容器和其他管線執行。

以下是新回應本文的範例。

"resources":
{
    "repositories":
    {
        "self":
        {
            "repository":
            {
                "id": "e5c55144-277b-49e3-9905-2dc162e3f663",
                "type": "azureReposGit"
            },
            "refName": "refs/heads/main",
            "version": "44153346ecdbbf66c68c20fadf27f53ea1394db7"
        },
        "MyFirstProject":
        {
            "repository":
            {
                "id": "e5c55144-277b-49e3-9905-2dc162e3f663",
                "type": "azureReposGit"
            },
            "refName": "refs/heads/main",
            "version": "44153346ecdbbf66c68c20fadf27f53ea1394db7"
        }
    },
    "pipelines":
    {
        "SourcePipelineResource":
        {
            "pipeline":
            {
                "url": "https://dev.azure.com/fabrikam/20317ad0-ae49-4588-ae92-6263028b4d83/_apis/pipelines/51?revision=3",
                "id": 51,
                "revision": 3,
                "name": "SourcePipeline",
                "folder": "\\source"
            },
            "version": "20220801.1"
        }
    },
    "containers":
    {
        "windowscontainer":
        {
            "container":
            {
                "environment":
                {
                    "Test": "test"
                },
                "mapDockerSocket": false,
                "image": "mcr.microsoft.com/windows/servercore:ltsc2019",
                "options": "-e 'another_test=tst'",
                "volumes":
                [
                    "C:\\Users\\fabrikamuser\\mount-fabrikam:c:\\mount-fabrikam"
                ],
                "ports":
                [
                    "8080:80",
                    "6379"
                ]
            }
        }
    }
},
"templateParameters":
{
    "includeTemplateSteps": "True"
}

在 YAML 範本運算式中新增字串分割函式的支援

YAML 管線可讓您方便減少程式碼重複的方式,例如 迴圈查看 each 物件清單 或屬性的值。

有時候,要逐一查看的專案集會以字串表示。 例如,當要部署的環境清單是由字串 integration1, integration2 所定義時。

當我們從開發人員社群聆聽您的意見反應時,我們聽到您想要 YAML 範本運算式中的字串 split 函式。

現在,您可以 split 字串並逐一查看 each 其子字串。

variables:
  environments: integration1, integration2

jobs:
  - job: Deploy
    steps:
    - ${{ each env in split(variables.environments, ', ') }}:
      - script: ./deploy.sh -e ${{ env }}
      - script: ./runTest.sh -e ${{ env }}

擷取 Git 存放庫時不要同步標記

簽出工作會使用 --tags 選項來擷取 Git 存放庫的內容。 這會導致伺服器擷取所有標記,以及這些標記所指向的所有物件。 這會增加在管線中執行工作的時間,特別是如果您有大量標籤的存放庫。 此外,即使啟用淺層擷取選項,簽出工作也會同步標記,因而可能會破壞其用途。 為了減少從 Git 存放庫擷取或提取的資料量,我們現在已將新選項新增至工作,以控制同步標記的行為。 此選項可在傳統和 YAML 管線中使用。

此行為可以從 YAML 檔案或 UI 控制。

若要選擇不要透過 YAML 檔案同步標記,請將 新增 fetchTags: false 至簽出步驟。 fetchTags未指定選項時,它與使用的選項相同 fetchTags: true

steps:
- checkout: self  # self represents the repo where the initial Pipelines YAML file was found
  clean: boolean  # whether to fetch clean each time
  fetchTags: boolean # whether to sync the tags
  fetchDepth: number  # the depth of commits to ask Git to fetch
  lfs: boolean  # whether to download Git-LFS files
  submodules: boolean | recursive  # set to 'true' for a single level of submodules or 'recursive' to get submodules of submodules
  path: string  # path to check out source code, relative to the agent's build directory (e.g. \_work\1)
  persistCredentials: boolean  # set to 'true' to leave the OAuth token in the Git config after the initial fetch

如果您想要變更現有 YAML 管線的行為,在 UI 中設定此選項可能會比較方便,而不是更新 YAML 檔案。 若要流覽至 UI,請開啟管線的 YAML 編輯器,選取 [觸發程式],然後選取 [處理],然後開啟 [簽出] 步驟。

如果您在 YAML 檔案和 UI 中同時指定此設定,則 YAML 檔案中指定的值優先。

針對您建立的所有新管線 (YAML 或傳統) ,標籤預設仍會同步處理。 此選項不會變更現有管線的行為。 除非您明確變更選項,否則這些管線中的標記仍會同步。

已更新 Ubuntu 18.04 映射的 brownout 排程

Azure Pipelines 已淘汰裝載集區上的 Ubuntu 18.04 映射 (ubuntu-18.04) 。 此映射將于 12 月 1 日淘汰。 您可能會開始看到較長的佇列時間。

為了協助您更清楚地識別使用 ubuntu-18.04 映射的管線,我們正在規劃散發。 作業會在中斷期間失敗。

  • 使用 ubuntu-18.04 映射在管線執行上顯示警告訊息
  • 腳本可用來協助您使用已被取代的映射來尋找管線,包括 ubuntu-18.04
  • 我們正在排程簡短的「中斷」。 任何 ubuntu-18.04 執行都會在中斷期間失敗。 因此,建議您先移轉管線,再移轉您的管線。

更新) (的 Brownout 排程

  • 10 月 3 日,12:00 UTC - 10 月 3 日,14:00 UTC
  • 10 月 18 日,14:00 UTC - 10 月 18 日,16:00 UTC
  • 11 月 15 日,18:00 UTC - 11 月 15 日,20:00 UTC
  • 20:00 UTC - 11 月 30 日,22:00 UTC
  • 20:00 UTC - 12 月 16 日 00:00 UTC
  • 10.00 UTC 1 月 5 日 - 14.00 UTC
  • 12.00 UTC 13 年 1 月 13 日 - 16.00 UTC
  • January 18, 14.00 UTC - January 18, 18.00 UTC
  • 20.00 UTC 16.00 年 1 月 24 日 - 20.00 UTC
  • 2 月 1 日 18.00 UTC - 22.00 UTC 2 月 1 日
  • 2 月 7 日 16.00 UTC - 22.00 UTC 2 月 7 日
  • 2 月 13 日 14.00 UTC - 22.00 UTC 2 月 13 日
  • 21 年 2 月 21 日,10.00 UTC - 21 年 2 月 21 日 UTC
  • 2 月 28 日,10.00 UTC - 22.00 UTC 28 日
  • 3 月 6 日,00.00 UTC - 3 月 7 日 00.00 UTC
  • 3 月 13 日,00.00 UTC - 3 月 14 日,00.00 UTC
  • 3 月 21 日,00.00 UTC - 3 月 22 日,00.00 UTC

後續步驟

注意

這些功能將在接下來兩到三周推出。

請前往 Azure DevOps 並查看。

如何提供意見反應

我們希望聽到您對這些功能的想法。 使用說明功能表來回報問題或提供建議。

提供建議

您也可以在 Stack Overflow上取得社群所回答的建議和問題。

感謝您!

Aaron Hallberg