次の方法で共有

タスクの種類と使用方法

  • [アーティクル]

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

タスクは、一連の入力で抽象化されたスクリプトまたはプロシージャのパッケージであり、パイプライン内でアクションを実行します。 タスクは、パイプライン内で自動化を定義するための構成ブロックです

ジョブを実行すると、すべてのタスクが一つずつ順番に実行されます。 複数のエージェントで同じタスク セットを並列で実行する場合、またはエージェントを使用せずに一部のタスクを実行する場合については、ジョブに関するページを参照してください。

既定では、すべてのタスクは、ホスト上でもジョブ コンテナー上でも、同じコンテキストで実行されます。

必要に応じてステップ ターゲットを使用し、個々のタスクのコンテキストを制御することもできます。

組み込みタスクを使用したタスクのプロパティを指定する方法の詳細を確認してください。

ジョブを実行すると、エージェントですべてのタスクが一つずつ順番に実行されます。 複数のエージェントで同じタスク セットを並列で実行する場合、またはエージェントを使用せずに一部のタスクを実行する場合については、ジョブに関するページを参照してください。

タスクでサポートされる一般的な属性の詳細については、steps.task の YAML リファレンスを参照してください。

カスタム タスク

Azure DevOps には、基本的なビルドとデプロイのシナリオを可能にするための組み込みタスクが含まれています。 また、独自のカスタム タスクを作成することもできます。

さらに、Visual Studio Marketplace には多くの拡張機能が用意されており、サブスクリプションまたはコレクションにインストールされると、1 つ以上のタスクでタスク カタログが拡張されます。 加えて、独自のカスタム拡張機能を記述して 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 では、タスク名に @ を使用してメジャー バージョンを指定します。 たとえば、PublishTestResults タスクのバージョン 2 にピン留めするには、次のようにします。

steps:
- task: PublishTestResults@2

YAML パイプラインは TFS では使用できません。

タスク制御オプション

各タスクには、いくつかの管理オプションが用意されています。

管理オプションは、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.

管理オプションは、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.

注意

特定のタスクまたはジョブでは、ジョブ/ステージが続行されるかどうかを一方的に決定することはできません。 できることは、成功または失敗の状態を提供することです。ダウンストリームのタスク/ジョブにはそれぞれ、実行するかどうかを決定できる条件の評価があります。 既定の条件は、効果的に "正常な状態の場合は実行する" というものです。

[エラー時に続行する] でこれを微調整することができます。 すべてのダウンストリームのステップ/ジョブを効果的に "仕向ける" ことで、その判断を下す目的ですべての結果を "成功" として扱わせます。 または、別の言い方をすれば、"含まれている構造体の条件について判断を下すときに、このタスクの失敗を考慮しない" ということです。

タイムアウト期間は、タスクの実行が開始されたときに開始されます。 これには、タスクがキューに入っている時間やエージェントを待機している時間は含まれません。

Note

パイプラインには、タスク レベルのタイムアウトに加えて、ジョブ レベルのタイムアウトが指定されている場合があります。 ステップが完了する前にジョブ レベルのタイムアウト間隔が経過すると、タスクのタイムアウト間隔が長く設定されている場合でも、実行中のジョブは終了します。 詳細については、「Timeouts」を参照してください。

この 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 を使用します。 既定値は、再試行回数 0 回です。 タスクのプロパティの詳細については、YAML スキーマの steps.task に関する記事を参照してください。

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

Note

YAML パイプラインは TFS では使用できません。

環境変数

各タスクには env プロパティがり、タスク プロセスにマップされた環境変数を表す文字列ペアの一覧が示されます。

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

次の例では、script ステップを実行します。これは、コマンド ライン タスクのショートカットであり、その後には同等のタスク構文が続きます。 この例では、Azure DevOps CLI での認証に使用される AZURE_DEVOPS_EXT_PAT 環境変数に値を割り当てます。

# 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
  ...

次の例では、Bash@3 のショートカットである script ステップを実行しており、その後に等価の task 構文を示しています。 この例では、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)

ツール インストーラーを使用すると、ビルド パイプラインで依存関係をインストールおよび制御できます。 具体的には次のことができます。

  • CI ビルドに合わせて、ツールまたはランタイムをすぐに (Microsoft でホストされているエージェントでも) インストールする。

  • 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 バージョンの場所をログに記録します。

YAML パイプラインは TFS では使用できません。

ツール インストーラー タスク

ツール インストーラー タスクの一覧については、ツール インストーラー タスクに関するページを参照してください。

インボックスと Marketplace タスクの無効化

組織の設定ページでは、Marketplace タスク、インボックス タスク、またはその両方を無効にすることができます。 Marketplace タスクを無効にすると、パイプラインのセキュリティを強化できます。 インボックスと Marketplace タスクの両方を無効にした場合は、tfx を使用してインストールしたタスクのみを使用できます。

ヘルプとサポート