パイプラインのスケジュールを構成する

Note

Microsoft Team Foundation Server (TFS) 2018 以前のバージョンでは、ビルドとリリースの "パイプライン" は "定義"、"実行" は "ビルド"、"サービス接続" は "サービス エンドポイント"、"ステージ" は "環境"、"ジョブ" は "フェーズ" と呼ばれます。

Azure Pipelines には、パイプラインの開始方法を構成するためのいくつかの種類のトリガーが用意されています。

  • スケジュールされたトリガーは、夜間ビルドなどのスケジュールに基づいてパイプラインを開始します。 この記事では、スケジュールされたトリガーを使用して、スケジュールに基づいてパイプラインを実行する方法について説明します。
  • イベントベースのトリガーは、プル要求の作成や分岐へのプッシュなどのイベントに応答してパイプラインを開始します。 イベントベースのトリガーの使用の詳細については、「 Azure Pipelines のトリガー」を参照してください。

パイプラインでスケジュールされたトリガーとイベントベースのトリガーを組み合わせることができます。たとえば、プッシュが行われるたびにビルドを検証する (CI トリガー)、プル要求が行われたとき (PR トリガー)、夜間のビルド (スケジュールされたトリガー) を使用できます。 イベントベースのトリガーに応答せずに、スケジュールに従ってのみパイプラインをビルドする場合は、パイプラインに他のトリガーが有効になっていないことを確認します。 たとえば、GitHub リポジトリの yaml パイプラインには、CI トリガーと PR トリガーが既定で有効になっています。 既定のトリガーを無効にする方法の詳細については、「 Azure Pipelines のトリガー 」を参照して、リポジトリの種類に関するセクションに移動してください。

スケジュールされたトリガー

重要

パイプライン設定 UI を使用して定義されたスケジュールされたトリガーは、YAML のスケジュールされたトリガーよりも優先されます。

YAML パイプラインに YAML スケジュールされたトリガーと UI が定義されているトリガーの両方がある場合は、スケジュールされた UI 定義のトリガーだけが実行されます。 Yaml パイプラインで定義済みのスケジュールされたトリガーを実行するには、パイプライン設定 UI で定義されているスケジュールされたトリガーを削除する必要があります。 すべての UI のスケジュールされたトリガーを削除したら、YAML のスケジュールされたトリガーを評価するためにプッシュを行う必要があります。

YAML パイプラインから UI スケジュールされたトリガーを削除するには、「 ui 設定オーバーライド yaml スケジュールされたトリガー」を参照してください。

スケジュールされたトリガーは、 cron 構文を使用して定義されたスケジュールで実行するようにパイプラインを構成します。

schedules:
- cron: string # cron syntax defining a schedule
  displayName: string # friendly name given to a specific schedule
  branches:
    include: [ string ] # which branches the schedule applies to
    exclude: [ string ] # which branches to exclude from the schedule
  always: boolean # whether to always run the pipeline or only if there have been source code changes since the last successful scheduled run. The default is false.

YAML のスケジュールされたパイプラインには、次の制約があります。

  • Cron スケジュールのタイムゾーンは UTC です。
  • に句を指定せずに句を指定すると excludeinclude 、句でを branches 指定するのと同じ結果になり *include ます。
  • スケジュールを指定するときに、パイプライン変数を使用することはできません。
  • YAML ファイルでテンプレートを使用する場合、スケジュールは、テンプレートファイルではなく、メインの yaml ファイルで指定する必要があります。

スケジュールされたトリガーの分岐に関する考慮事項

次のイベントが発生すると、スケジュールされたトリガーが分岐に対して評価されます。

  • パイプラインが作成されます。
  • パイプラインの YAML ファイルは、プッシュから、またはパイプラインエディターで編集することによって更新されます。
  • パイプラインの YAML ファイルパスが更新され、 別の YAML ファイルが参照されます。 この変更によって既定のブランチのみが更新されるため、既定のブランチの更新された YAML ファイルでのみスケジュールが選択されます。 その後、その他の分岐が既定の分岐をマージする場合は、 git pull origin main 新しく参照された YAML ファイルのスケジュールされたトリガーがその分岐に対して評価されます。
  • 新しいブランチが作成されます。

これらのイベントのいずれかが分岐で発生すると、その分岐に対してスケジュールされた実行が追加されます。その分岐が、その分岐の YAML ファイルに含まれるスケジュールされたトリガーの分岐フィルターと一致する場合は、その分岐が追加されます。

重要

分岐に対してスケジュールされた実行が追加されるのは、分岐が、 その特定の分岐のyaml ファイル内のスケジュールされたトリガーの分岐フィルターと一致する場合のみです。

たとえば、次のスケジュールでパイプラインが作成され、このバージョンの YAML ファイルが分岐にチェックインされ main ます。 このスケジュールは、 main 1 日単位でブランチを構築します。

# YAML file in the main branch
schedules:
- cron: "0 0 * * *"
  displayName: Daily midnight build
  branches:
    include:
    - main

次に、という名前のの新しい分岐を作成 mainnew-feature します。 新しい分岐の YAML ファイルからスケジュールされたトリガーが読み取られます。分岐に一致するものがないため、スケジュールされたビルドには変更が行われず、スケジュールされた new-featurenew-feature トリガーを使用して分岐が構築されることはありません。

new-featureがリストに追加され、 branches この変更が分岐にプッシュされた場合 new-feature 、yaml ファイルが読み取られます。これで、がブランチリストに追加されたため、 new-feature 分岐に対してスケジュールされたビルドが追加され new-feature ます。

# YAML file in the new-feature-branch
schedules:
- cron: "0 0 * * *"
  displayName: Daily midnight build
  branches:
    include:
    - main
    - new-feature

ここで、という名前のブランチがに基づいて作成されている releasemain とします。その後、ブランチ release 内の yaml ファイルの分岐フィルターに追加され main ますが、新しく作成されたブランチには追加されません release

# YAML file in the release branch
schedules:
- cron: "0 0 * * *"
  displayName: Daily midnight build
  branches:
    include:
    - main

# YAML file in the main branch with release added to the branches list
schedules:
- cron: "0 0 * * *"
  displayName: Daily midnight build
  branches:
    include:
    - main
    - release

は分岐の分岐フィルターに追加されましたが、分岐の分岐フィルターには追加されて releasemainrelease ため、 releaserelease そのスケジュールに基づいて分岐が構築されることはありません。 featurefeatureの yaml ファイルの分岐フィルターに分岐を追加した場合にのみ、スケジュールされたビルドがスケジューラに追加されます。

スケジュールされたビルドは、Azure DevOps Server 2019 の yaml 構文ではサポートされていません。 YAML ビルドパイプラインを作成したら、パイプライン設定を使用して、スケジュールされたトリガーを指定できます。

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

次の例では、2つのスケジュールを定義します。

schedules:
- cron: "0 0 * * *"
  displayName: Daily midnight build
  branches:
    include:
    - main
    - releases/*
    exclude:
    - releases/ancient/*
- cron: "0 12 * * 0"
  displayName: Weekly Sunday build
  branches:
    include:
    - releases/*
  always: true

最初のスケジュール ( 毎日午前 0時) は、1日の午前0時にパイプラインを実行しますが、最後にスケジュールされた前回の実行以降に変更があった場合のみ releases/*releases/ancient/* です。

2番目のスケジュール ( 毎週日曜日のビルド) では、コードが変更されたかどうかにかかわらず、すべての分岐について、最後の実行以降に行われなかったかどうかにかかわらず、正午にパイプラインを実行し ます。

Note

Cron スケジュールのタイムゾーンは UTC です。そのため、これらの例では、真夜中のビルドと正午のビルドは UTC の午前0時と正午になります。

その他の例については、「 クラシックエディターからの移行」を参照してください。

スケジュールされたビルドは、Azure DevOps Server 2019 の yaml 構文ではサポートされていません。 YAML ビルドパイプラインを作成したら、パイプライン設定を使用して、スケジュールされたトリガーを指定できます。

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

Cron 構文

各 Azure Pipelines スケジュールされたトリガー cron 式は、次の順序で5つのエントリを含むスペース区切り式です。

mm HH DD MM DW
 \  \  \  \  \__ Days of week
  \  \  \  \____ Months
   \  \  \______ Days
    \  \________ Hours
     \__________ Minutes
フィールド 指定可能な値
0 ~ 59
時間 0 ~ 23
日間 1 ~ 31
Months 1 ~ 12、完全な英語名、最初の 3 文字の英語名
週の日数 0 ~ 6 (日曜日から始まる)、完全な英語名、最初の 3 文字の英語名

値は次の形式で指定できます。

Format 説明
ワイルドカード * このフィールドのすべての値と一致します
単一値 5 このフィールドの 1 つの値を指定します
コンマ区切り 3,5,6 このフィールドに複数の値を指定します。 のような複数の形式を組み合わせることができます。 1,3-6
範囲 1-3 このフィールドの値の範囲を含む
頻度 */4 または 1-5/2 このフィールドに一致する間隔 (4 番目の値ごとに、またはステップ間隔が 2 の 1 ~ 5 の範囲など)
Cron 式
毎週月曜日、水曜日、金曜日の午後 6 時にビルドする 0 18 * * Mon,Wed,Fri0 18 * * 1,3,5、または 0 18 * * 1-5/2
6 時間ごとにビルドする 0 0,6,12,18 * * *0 */6 * * * または 0 0-18/6 * * *
午前 9:00 から 6 時間ごとにビルドする 0 9,15,21 * * * または 0 9-21/6 * * *

サポートされている形式の詳細については 、「Crontab 式」を参照してください

スケジュールされたビルドは、2019 年 1 月の YAML 構文Azure DevOps Serverサポートされていません。 YAML ビルド パイプラインを作成した後、パイプライン設定を使用してスケジュールされたトリガーを指定できます。

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

スケジュールされた実行ビュー

今後予定されているスケジュールされたビルドのプレビューを表示するには、パイプラインのパイプラインの詳細ページのコンテキスト メニューから [スケジュールされた実行]を選択します。

[スケジュールされた実行] メニュー

スケジュールされたトリガーを作成または更新した後は、このビューを使用してそれらを確認できます。

スケジュールされた実行

この例では、次のスケジュールのスケジュールされた実行を表示します。

schedules:
- cron: "0 0 * * *"
  displayName: Daily midnight build
  branches:
    include:
    - main

[スケジュールされた実行] ウィンドウには、ポータルを参照するために使用されるコンピューターで設定されたローカル タイム ゾーンに変換された時刻Azure DevOpsされます。 この例では、EST タイム ゾーンで撮影されたスクリーンショットを表示します。

スケジュールされたビルドは、2019 年 1 月の YAML 構文Azure DevOps Serverサポートされていません。 YAML ビルド パイプラインを作成した後、パイプライン設定を使用してスケジュールされたトリガーを指定できます。

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

コードの変更がない場合でも実行される

Note

スケジュールされたビルドは、TFS 2018.1 以下のコード変更に関係なく、常にスケジュールに基いて実行されます。

既定では、前回のスケジュールされた実行以降にコードが変更されていない場合、パイプラインはスケジュールされたとして実行されません。 たとえば、毎夜午後 9 時に実行するパイプラインをスケジュールしたとします。 平日は、さまざまな変更をコードにプッシュします。 パイプラインはスケジュールに基して実行されます。 週末は、コードに変更を加える必要はありません。 金曜日にスケジュールされた実行以降にコードの変更がない場合、パイプラインは週末にスケジュールされた通り実行されません。

コードの変更がない場合でもパイプラインを強制的に実行するには、 キーワードを使用 always します。

schedules:
- cron: ...
  ...
  always: true

スケジュールされたビルドは、このバージョンの YAML 構文ではサポートAzure DevOps Server。 YAML ビルド パイプラインを作成した後、パイプライン設定を使用してスケジュールされたトリガーを指定できます。

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

スケジュールされた実行の数の制限

実行するパイプラインをスケジュールできる頻度には、一定の制限があります。 これらの制限は、リソース (特に Microsoft でホストされているエージェント) Azure Pipelines誤用を防ぐために設定されています。 この制限は、1 週間あたりパイプラインあたり約 1,000 回の実行です。

クラシック エディターからの移行

次の例では、クラシック エディターから YAML にスケジュールを移行する方法を示します。

例: 複数のタイム ゾーンでの Git リポジトリの夜間ビルド

この例では、クラシック エディターのスケジュールされたトリガーに 2 つのエントリが含まれるので、次のビルドが生成されます。

  • 毎週月曜日から金曜日の午前 3 時 (UTC + 5:30 タイム ゾーン)、ブランチ フィルター条件を満たす features/india/* ブランチをビルドする

    スケジュールされたトリガー UTC + 5:30 タイム ゾーン

  • 毎週月曜日から金曜日の午前 3 時 (UTC - 5:00 タイム ゾーン)、ブランチ フィルター条件を満たす features/nc/* ブランチをビルドする

    スケジュールされたトリガー UTC -5:00 タイム ゾーン

同等の YAML スケジュールされたトリガーは次です。

schedules:
- cron: "30 21 * * Sun-Thu"
  displayName: M-F 3:00 AM (UTC + 5:30) India daily build
  branches:
    include:
    - /features/india/*
- cron: "0 8 * * Mon-Fri"
  displayName: M-F 3:00 AM (UTC - 5) NC daily build
  branches:
    include:
    - /features/nc/*

最初のスケジュールでは 、M-F 3:00 AM (UTC + 5:30) インドの毎日のビルドで、cron 構文 ( ) は です 30 21 * * Sun-Thu

  • 分と時間 - 30 21 ( ) にマップ 21:30 UTC されます 9:30 PM UTC 。 クラシック エディターの指定されたタイム ゾーンは UTC + 5:30です。YAML トリガーに指定する目的の UTC 時刻に到着するには、目的のビルド時刻の午前 3 時から 5 時間 30 分を減算する必要があります。
  • 日と月はワイルドカードとして指定されます。このスケジュールでは、月の特定の日または特定の月にのみ実行するが指定されていません。
  • 週の日数 - タイムゾーン変換のため、ビルドを UTC + 5:30 インド のタイム ゾーンの午前 Sun-Thu 3 時 00 分に実行するには、UTC 時刻で前の日の開始を指定する必要があります。 また、週の日数を または として指定 0-4 できます 0,1,2,3,4

2 番目のスケジュールでは 、M-F 3:00 AM (UTC - 5) NC の毎日のビルドで、cron 構文は です

  • 分と時間 - 0 8 これは にマップされます 8:00 AM UTC 。 クラシック エディターの指定されたタイム ゾーンは UTC - 5:00です。YAML トリガーに指定する目的の UTC 時刻に到着するには、目的のビルド時刻の午前 3 時から 5 時間を追加する必要があります。
  • 日と月はワイルドカードとして指定されます。このスケジュールでは、月の特定の日または特定の月にのみ実行するが指定されていません。
  • 週の日数 - タイムゾーン変換は、目的のスケジュールの週の複数の日にまたがるのではないので、ここでは変換を行う Mon-Fri 必要はありません。 また、週の日数を または として指定 1-5 できます 1,2,3,4,5

重要

YAML スケジュールされたトリガーの UTC タイム ゾーンでは、夏時間は考慮されません。

ヒント

週の 3 文字の日を使用し、Sun を通じて複数日のスパンが必要な場合、Sun は週の最初の日と見なす必要があります。たとえば、EST の午前 0 時、木曜日から日曜日のスケジュールの場合、cron 構文は です。 0 5 * * Sun,Thu-Sat

例: 頻度が異なる夜間ビルド

この例では、クラシック エディターのスケジュールされたトリガーに 2 つのエントリが含まれるので、次のビルドが生成されます。

  • 毎週月曜日から金曜日の午前 3 時 (UTC) に、 および ブランチ フィルター条件を満たす mainreleases/* ブランチを作成します

    スケジュールされたトリガーの頻度 1。

  • 毎週日曜日の午前 3 時 (UTC) に、ソースまたはパイプラインが変更されなくても、ブランチ releases/lastversion をビルドします

    スケジュールされたトリガーの頻度 2。

同等の YAML スケジュールされたトリガーは次です。

schedules:
- cron: "0 3 * * Mon-Fri"
  displayName: M-F 3:00 AM (UTC) daily build
  branches:
    include:
    - main
    - /releases/*
- cron: "0 3 * * Sun"
  displayName: Sunday 3:00 AM (UTC) weekly latest version build
  branches:
    include:
    - /releases/lastversion
  always: true

最初のスケジュールでは、 毎日午前 3 時 (UTC)にビルドされます。cron 構文は です

  • 分と時間 - 0 3 これは にマップされます 3:00 AM UTC 。 クラシック エディターの指定されたタイム ゾーンは UTCです。タイム ゾーン変換を行う必要は一切ない。
  • 日と月はワイルドカードとして指定されます。このスケジュールでは、月の特定の日または特定の月にのみ実行するが指定されていません。
  • [日数] - タイムゾーン変換が行えないので、クラシック エディター のスケジュールからその日 Mon-Fri が直接マップされます。 また、週の日数を として指定できます 1,2,3,4,5

2 番目のスケジュールでは 、毎週の最新バージョンビルドである日曜日の午前 3 時 (UTC)に、cron 構文は です

  • 分と時間 - 0 3 これは にマップされます 3:00 AM UTC 。 クラシック エディターの指定されたタイム ゾーンは UTCです。タイム ゾーン変換を行う必要は一切ない。
  • 日と月はワイルドカードとして指定されます。このスケジュールでは、月の特定の日または特定の月にのみ実行するが指定されていません。
  • 週の日数 - タイムゾーン変換は、目的のスケジュールの週の複数の日にまたがるのではないので、ここでは変換を行う Sun 必要はありません。 また、週の日数を として指定できます 0
  • また、このビルドは、ソース コードが更新されたかどうかを実行するスケジュールが設定 always: true されています。

よく寄せられる質問

YAML ファイルでスケジュールを定義しました。 しかし、実行されません。 何が起きましたか?

  • パイプラインに対してスケジュールされているAzure Pipelinesいくつかの実行を確認します。 これらは、パイプラインで [スケジュールされた実行] アクションを 選択することで確認できます。 この一覧はフィルター処理され、今後数日間の実行数だけが表示されます。 これが期待を満たしていない場合は、cron スケジュールを誤って入力した場合や、正しい分岐でスケジュールが定義されていない可能性があります。 スケジュールを構成する方法については、上記のトピックを参照してください。 cron 構文を再評価します。 cron スケジュールのすべての時刻は UTC です。

  • YAML ファイルに小さな簡単な変更を加え、その更新プログラムをリポジトリにプッシュします。 前に YAML ファイルからスケジュールを読み取る際に問題が発生した場合は、ここで修正する必要があります。

  • UI で定義されているスケジュールがある場合、YAML スケジュールは受け入れされません。 パイプラインのエディターに移動し、[トリガー] を選択して、UI スケジュールが設定されていないこと を確認します

  • パイプラインのスケジュールを設定できる実行の数には制限があります。 詳細については、制限に関 する記事を参照してください

  • コードに変更がない場合は、新Azure Pipelinesが開始されない可能性があります。 この動作をオーバーライド する方法 について学習します。

YAML スケジュールは問題ありません。 しかし、彼らは今は動作を停止しました。 操作方法デバッグしますか?

  • を指定しなかった場合、コードに対して行われた更新がない限り、パイプライン always:true はスケジュールされます。 コードが変更されたかどうか、およびスケジュール を構成した 方法を確認します

  • パイプラインを スケジュール できる回数には制限があります。 これらの制限を超えているか確認します。

  • 他のユーザーが UI で追加のスケジュールを有効にした場合に確認します。 パイプラインのエディターを開き、 [トリガー] を選択します。 UI でスケジュールを定義した場合、YAML スケジュールは受け入れされません。

  • パイプラインが一時停止または無効になっているか確認します。 パイプライン設定を選択します。

  • パイプラインに対してスケジュールされているAzure Pipelinesいくつかの実行を確認します。 これらは、パイプラインで [スケジュールされた実行] アクションを 選択することで確認できます。 予期したスケジュールが表示されない場合は、YAML ファイルに小さな簡単な変更を加え、リポジトリに更新プログラムをプッシュします。 これにより、スケジュールが再同期されます。

  • コードの格納に GitHub を使用すると、新しい実行を開始しようとして Azure Pipelines によって GitHub が調整されている可能性があります。 新しい実行を手動で開始できるのか確認します。

コードは変更されていませんが、スケジュールされたビルドがトリガーされます。 なぜですか?

  • コードの変更がない場合でも 、スケジュールされた ビルドを常に実行するオプションを有効にしている可能性があります。 YAML ファイルを使用する場合は、YAML ファイルでスケジュールの構文を確認します。 クラシック パイプラインを使用する場合は、スケジュールされたトリガーでこのオプションをオンにした場合に確認します。

  • ビルド パイプラインまたはパイプラインの一部のプロパティを更新した可能性があります。 これにより、ソース コードを更新していない場合でも、新しい実行がスケジュールされます。 クラシック エディター を使用 して、パイプラインの変更の履歴を確認します。

  • リポジトリへの接続に使用するサービス接続を更新した可能性があります。 これにより、ソース コードを更新していない場合でも、新しい実行がスケジュールされます。

  • Azure Pipelines、コードに更新プログラムが適用されていないか確認します。 リポジトリAzure Pipelinesアクセスできない場合、またはこの情報を取得できない場合は、スケジュールされた実行が開始されるか、失敗した実行が作成され、リポジトリに到達できないというメッセージが表示されます。 実行が作成され、すぐに失敗した場合は、これが原因である可能性があります。 これは、リポジトリにアクセスできないAzure Pipelines知らせるダミーのビルドです。

[スケジュールされた実行] パネルに計画された実行が表示されます。 ただし、その時点では実行されません。 なぜですか?

  • [ スケジュールされた実行] パネルには、考え得るすべてのスケジュールが表示されます。 ただし、コードを実際に更新していない限り、実際には実行されない場合があります。 スケジュールを強制的に常に実行するには、YAML パイプラインで always プロパティを設定するか、クラシック パイプラインで常に実行するオプションをオンにしてください。

YAML パイプラインで定義されたスケジュールは、一方のブランチでは機能しますが、もう一方のブランチでは機能しません。 これをどのように修正すればよいですか?

スケジュールは YAML ファイルで定義され、これらのファイルはブランチに関連付けされます。 たとえば、特定のブランチに対してパイプラインをスケジュールする場合は、そのブランチの YAML ファイルに cron スケジュールが定義され、スケジュールに適切なブランチ インクルードが含まれることを確認します。 features/Xfeatures/X この例では、ブランチの YAML ファイル features/X に次の情報が含まれる必要があります。

schedules: 
- cron: "0 12 * * 0"   # replace with your schedule 
  branches: 
    include: 
    - features/X  

詳細については、「スケジュールされたトリガーの ブランチに関する考慮事項」を参照してください