工作類型與使用方式

  • 發行項

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019

工作會在管線中執行動作，而且是使用一組輸入來抽象的封裝腳本或程式。 工作是在管線中定義自動化的建置組塊。

當您執行 作業時，所有工作都會依序執行，一個接一個。 若要在多個代理程式上平行執行同一組工作，或不使用代理程式來執行某些工作，請參閱 作業。

根據預設，所有工作都會在相同的內容中執行，無論是在主機上還是作業容器中。

您可以選擇性地使用 步驟目標 來控制個別工作的內容。

深入瞭解如何使用內建工作來指定工作的屬性。

當您執行 作業時，所有工作都會依序在代理程式上依序執行。 若要在多個代理程式上平行執行同一組工作，或不使用代理程式來執行某些工作，請參閱 作業。

若要深入瞭解工作支援的一般屬性，請參閱 steps.task 的 YAML 參考。

自訂工作

Azure DevOps 包含 內建工作 ，可啟用基本建置和部署案例。 您也可以 建立自己的自定義工作。

此外， Visual Studio Marketplace 提供許多延伸模組;每個延伸模組安裝到您的訂用帳戶或集合時，都會使用一或多個工作來擴充工作目錄。 您也可以撰寫自己的 自定義擴充 功能，將工作新增至 Azure Pipelines。

在 YAML 管線中，您可以依名稱參考工作。 如果名稱同時符合內建工作和自定義工作，則內建工作會優先使用。 您可以使用工作 GUID 或自訂工作的完整名稱來避免此風險：

steps:
- task: myPublisherId.myExtensionId.myContributionId.myTaskName@1 #format example
- task: qetza.replacetokens.replacetokens-task.replacetokens@3 #working example

若要尋找 myPublisherId 和 myExtensionId，請選取 [取得 市集中的工作]。 URL 字串中的 之後 itemName 的值是 myPublisherId 和 myExtensionId。 您也可以將工作新增至 發行管線 ，並在編輯工作時選取 [檢視 YAML ] 來尋找完整名稱。

工作版本

工作已設定版本，您必須指定管線中使用的工作主要版本。 這有助於防止發行新版的工作時發生問題。 工作通常回溯相容，但在某些情況下，您可能會在工作自動更新時遇到無法預測的錯誤。

發行新的次要版本時（例如 1.2 到 1.3），您的管線會自動使用新版本。 不過，如果發行新的主要版本（例如 2.0），您的管線會繼續使用您指定的主要版本，直到您編輯管線，並手動變更為新的主要版本為止。 記錄檔會包含新的主要版本可供使用的警示。

您可以藉由在符號之後 @ 指定工作的完整版本號碼來設定使用哪個次要版本 （範例： GoTool@0.3.1。 您只能使用您 組織存在的工作版本。

在 YAML 中，您可以使用 在工作名稱中指定主要版本 @ 。 例如，若要釘選到工作的第 2 PublishTestResults 版：

steps:
- task: PublishTestResults@2

TFS 中無法使用YAML管線。

工作控制選項

每項工作都會提供您一些 控件選項。

控制項選項可在區段上 task 做為索引鍵。

- task: string # Required as first property. Name of the task to run.
  inputs: # Inputs for the task.
    string: string # Name/value pairs
  condition: string # Evaluate this condition expression to determine whether to run this task.
  continueOnError: boolean # Continue running even on failure?
  displayName: string # Human-readable name for the task.
  enabled: boolean # Run this task when the job runs?
  env: # Variables to map into the process's environment.
    string: string # Name/value pairs
  name: string # ID of the step.
  timeoutInMinutes: string # Time to wait for this task to complete before the server kills it.

控制項選項可在區段上 task 做為索引鍵。

- task: string # Required as first property. Name of the task to run.
  inputs: # Inputs for the task.
    string: string # Name/value pairs
  condition: string # Evaluate this condition expression to determine whether to run this task.
  continueOnError: boolean # Continue running even on failure?
  displayName: string # Human-readable name for the task.
  target: string | target # Environment in which to run this task.
  enabled: boolean # Run this task when the job runs?
  env: # Variables to map into the process's environment.
    string: string # Name/value pairs
  name: string # ID of the step.
  timeoutInMinutes: string # Time to wait for this task to complete before the server kills it.
  retryCountOnTaskFailure: string # Number of retries if the task fails.

控制項選項可在區段上 task 做為索引鍵。

- task: string # Required as first property. Name of the task to run.
  inputs: # Inputs for the task.
    string: string # Name/value pairs
  condition: string # Evaluate this condition expression to determine whether to run this task.
  continueOnError: boolean # Continue running even on failure?
  displayName: string # Human-readable name for the task.
  target: string | target # Environment in which to run this task.
  enabled: boolean # Run this task when the job runs?
  env: # Variables to map into the process's environment.
    string: string # Name/value pairs
  name: string # ID of the step.
  timeoutInMinutes: string # Time to wait for this task to complete before the server kills it.
  retryCountOnTaskFailure: string # Number of retries if the task fails.

注意

指定的工作或工作無法單方面決定作業/階段是否繼續。 其所能做的是提供成功或失敗的狀態，而下游工作/作業都有條件計算，讓他們決定是否要執行。 默認條件，實際上為「如果我們處於成功狀態，請執行」。

繼續錯誤 會以微妙的方式改變這個。 它有效地“欺騙”所有下游步驟/工作，將任何結果視為“成功”，以便做出該決定。 或者以另一種方式說，它表示“當您決定包含結構的條件時，不要考慮這項工作的失敗”。

當工作開始執行時，就會開始逾時期間。 它不包含工作排入佇列或正在等候代理程序的時間。

注意

除了工作層級逾時之外，管線可能會指定作業層級逾時。 如果作業層級逾時間隔在步驟完成之前經過，即使步驟設定了較長的逾時間隔，仍會終止執行中的作業。 如需詳細資訊，請參閱 逾時。

在此 YAML 中， PublishTestResults@2 即使上一個步驟因為 succeededOrFailed（） 條件而失敗，仍會執行。

steps:
- task: UsePythonVersion@0
  inputs:
    versionSpec: '3.x'
    architecture: 'x64'
- task: PublishTestResults@2
  inputs:
    testResultsFiles: "**/TEST-*.xml"
  condition: succeededOrFailed()

條件

  • 只有當具有相同代理程式集區的所有先前直接和間接相依性都成功時。 如果您有不同的代理程式集區，則這些階段或作業將會同時執行。 如果 YAML 中沒有設定條件，則這是預設值。

  • 即使先前的相依性失敗、除非已取消執行。 succeededOrFailed()在此條件的 YAML 中使用。

  • 即使先前的相依性失敗、即使已取消執行。 always()在此條件的 YAML 中使用。

  • 只有在先前的相依性失敗時。 failed()在此條件的 YAML 中使用。

步驟目標

工作會在執行內容中執行，也就是代理程式主機或容器。 個別步驟可能會藉由指定 target來覆寫其內容。 可用的選項是將代理程式主機加上管線中定義之任何容器的字 host 組。 例如：

resources:
  containers:
  - container: pycontainer
    image: python:3.11

steps:
- task: SampleTask@1
  target: host
- task: AnotherTask@1
  target: pycontainer

在這裡，會在 SampleTask 主機上執行，並在 AnotherTask 容器中執行。

工作失敗時的重試次數

使用 retryCountOnTaskFailure 來指定工作失敗時重試次數。 預設值為 0。

- task: <name of task>
   retryCountOnTaskFailure: <max number of retries>
   ...

注意

  • 需要代理程式 2.194.0 版或更新版本。 不支援無代理程式工作。
  • 失敗的工作會以秒為單位重試。 每次嘗試失敗之後，每次重試之間的等候時間都會增加。
  • 沒有關於工作等冪性的假設。 如果工作有副作用（例如，如果部分建立外部資源），則第二次執行時可能會失敗。
  • 沒有工作可用的重試計數相關信息。
  • 系統會將警告新增至工作記錄，指出在重試之前失敗。
  • 所有重試工作的嘗試都會顯示在UI中，做為相同工作節點的一部分。

TFS 中無法使用YAML管線。

環境變數

每個工作都有一個 env 屬性，這個屬性是字串組的清單，這些字串組代表對應至工作進程的環境變數。

task: AzureCLI@2
displayName: Azure CLI
inputs: # Specific to each task
env:
  ENV_VARIABLE_NAME: value
  ENV_VARIABLE_NAME2: value
  ...

下列範例會script執行步驟，這是命令行工作的快捷方式，後面接著對等的工作語法。 此範例會將值指派給 AZURE_DEVOPS_EXT_PAT 環境變數，用來向 Azure DevOps CLI 進行驗證。

# Using the script shortcut syntax
- script: az pipelines variable-group list --output table
  env:
    AZURE_DEVOPS_EXT_PAT: $(System.AccessToken)
  displayName: 'List variable groups using the script step'

# Using the task syntax
- task: CmdLine@2
  inputs:
    script: az pipelines variable-group list --output table
  env:
    AZURE_DEVOPS_EXT_PAT: $(System.AccessToken)
  displayName: 'List variable groups using the command line task'

建置工具安裝程式 （Azure Pipelines）

工具安裝程式可讓您的組建管線安裝及控制相依性。 具體而言，您可以：

  • 即時安裝工具或運行時間（即使是在 Microsoft 裝載的代理程式上），也會及時安裝 CI 組建。

  • 針對多個版本的相依性驗證您的應用程式或連結庫，例如Node.js。

例如，您可以設定組建管線，以針對多個版本的Node.js執行和驗證您的應用程式。

範例：在多個版本的 Node.js 上測試及驗證您的應用程式

使用下列內容，在專案的基底目錄中建立azure-pipelines.yml檔案。

pool:
  vmImage: ubuntu-latest

steps:
# Node install
- task: UseNode@1
  displayName: Node install
  inputs:
    version: '16.x' # The version we're installing
# Write the installed version to the command line
- script: which node

建立新的組建管線 並加以執行。 觀察組建的執行方式。 如果Node.js工具安裝程式尚未在代理程式上，則會下載Node.js版本。 命令行腳本會記錄磁碟上Node.js版本的位置。

TFS 中無法使用YAML管線。

工具安裝程式工作

如需工具安裝程式工作的清單，請參閱 工具安裝程式工作。

停用內建和 Marketplace 工作

在 [組織設定] 頁面上，您可以停用 Marketplace 工作、內建工作或兩者。 停用 Marketplace 工作有助於 提升管線的安全性 。 如果您同時停用內建和 Marketplace 工作，則只有您使用 安裝的工作可供使用 tfx 。

說明與支援