共用方式為

工作類型與使用方式

  • 發行項

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

工作控制選項

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

控制選項可在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.

控制項選項可在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 中設定任何條件，則此條件為預設值。

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

  • 即使先前的相依性失敗，即使執行被取消，也一樣。 在此條件的 YAML 中使用 always()。

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

步驟目標

工作會在執行的環境中運行，這個環境可以是代理程式主機或容器。 個別步驟可能會藉由指定 target 來覆寫其上下文。 可用選項包括目標代理主機的字 host 以及在管線中定義的任何容器。 例如：

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

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

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

工作失敗時的重試次數

使用 retryCountOnTaskFailure 來指定工作失敗時重試次數。 預設值為零次重試。 如需工作屬性的詳細資訊，請參閱 YAML 架構中的 steps.task。

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

注意

  • 需要代理程式 2.194.0 版或更新版本。 在 Azure DevOps Server 2022 上，對於無代理程式的任務不支援重試。 如需詳細資訊，請參閱 Azure DevOps 服務更新 2021 年 11 月 16 日 - 自動重試工作，以及 2025 年 6 月 14 日 Azure DevOps 服務更新 - 重試伺服器工作。
  • 允許的重試次數上限為10。
  • 每次嘗試失敗後，每次重試之間的等候時間會增加，並遵循指數退避策略。 第 1 次重試會在 1 秒之後發生，第 2 次重試 4 秒，第 10 次重試 100 秒。
  • 沒有對於任務的冪等性的假設。 如果工作有副作用（例如，如果部分建立外部資源），則第二次執行時可能會失敗。
  • 沒有可供任務使用的重試次數信息。
  • 系統會將警告新增至工作記錄，指出在重試之前失敗。
  • 所有重試工作的嘗試都會顯示在UI中，做為相同工作節點的一部分。

環境變數

每個工作都有一個 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'


- task: Bash@3
  inputs:
     targetType: # specific to each task
  env:
    ENV_VARIABLE_NAME: value
    ENV_VARIABLE_NAME2: value
  ...

下列範例會執行script後面接著相應的任務語法。 此範例會將一個值指派給環境變數 ENV_VARIABLE_NAME，並回顯該值。

# Using the script shortcut syntax
- script: echo "This is " $ENV_VARIABLE_NAME
  env:
    ENV_VARIABLE_NAME: "my value"
  displayName: 'echo environment variable'

# Using the task syntax
- task: Bash@2
  inputs:
    script: echo "This is " $ENV_VARIABLE_NAME
  env:
    ENV_VARIABLE_NAME: "my value"
  displayName: 'echo environment variable'

建置工具安裝程式 （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版本的位置。

工具安裝程式任務

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

停用內建和市場工作

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

說明與支援