web-dev-qa-db-ja.com

Azure DevopでYAMLパイプラインをトリガーする

Azure DevopsのYAMLビルドパイプラインは初めてで、トリガー機能に頭を抱えています。気になるのは、ブランチごとに異なるトリガーが必要だが、同じパイプラインを使用したいことです。

私が欲しいとしましょう

  1. Masterブランチのすべてのチェックインでビルドし、これをサーバーにデプロイする必要があります
  2. 毎晩、開発ブランチをビルドして別のサーバーにデプロイしたい

YamlファイルもGitにチェックインされるので混乱しています。スケジュールされたトリガーがある場合、CIトリガーも使用できないと読みました。

2つの.ymlファイルが必要ですか？それぞれを定義している？すべての手順を繰り返すのはクールではないようです

または、各ブランチに同じファイルの異なるバージョンが必要ですか？これはある時点でマージされませんか？

おまけの質問：マスターのトリガーを使用してDevelopemtブランチにビルドパイプラインをプッシュするとどうなりますか？ （めまいめまい）

azure-devopsazure-pipelinesazure-pipelines-release-pipeline
3
Jepzen

スケジュールされたトリガーとCIトリガーを設定することはできませんが、これは正しくありません。ドキュメントをチェックしてください ここ 。

スケジュールされたトリガーのみを使用してパイプラインを実行する場合は、YAMLファイルでpr：noneおよびtrigger：noneを指定して、PRおよび継続的統合トリガーを無効にする必要があります。 Azure Repos Gitを使用している場合、PRビルドはブランチポリシーを使用して構成され、そこで無効にする必要があります。

したがって、ここには2つのオプションがあります。

  1. すべてを1つのYAMLファイルに保持し、適切なサーバーにデプロイするための条件でどのブランチまたはどのようにビルドがトリガーされたかを確認します
  2. 2つのビルドを作成できますが、繰り返しを避けるために、一般的なものをテンプレートに抽出し、ビルド定義で再利用します（この場合、実際には、3つのyamlファイルを使用します）。

いくつかの例：

  • あなたはマスターブランチのみのジョブを実行したい：
jobs:
- job: A
  steps:
  - script: echo hello

- job: B
  dependsOn: A
  condition: and(succeeded(), eq(variables['build.sourceBranch'], 'refs/heads/master'))
  steps:
  - script: echo this only runs for master
  • 一般的なステップを抽出してビルド定義で再利用したい

一般的な手順：

# File: simple-param.yml
parameters:
- name: yesNo # name of the parameter; required
  type: boolean # data type of the parameter; required
  default: false

steps:
- script: echo ${{ parameters.yesNo }}

ビルド定義：

# File: Azure-pipelines.yml
trigger:
- master

extends:
  template: simple-param.yml
  parameters:
      yesNo: false # set to a non-boolean value to have the build fail

テンプレートについては ドキュメント で読むか、私の例 ブログ投稿 を確認してください。

従来のリリースパイプラインが必要な場合は、特定のブランチへのトリガーを持つ2つのリリースパイプラインを定義する必要があります。

Continous trigger for release pipeline

要約すると、あなたはあなたが望むことをすることができ、これを達成するための複数の方法があります。私の個人的な推奨事項は、テンプレートで個別のパイプラインを使用することです。これにより、ビルド定義が条件よりもきれいになり、どのブランチまたはどのようにビルドがトリガーされたかを確認できます。

この変数Build.Reasonブランチがトリガーされた方法を確認できます。

  • 手動：ユーザーが手動でビルドをキューに入れました。
  • IndividualCI：Git PushまたはTFVCチェックインによってトリガーされる継続的インテグレーション（CI）。
  • BatchedCI：GitプッシュまたはTFVCチェックインによってトリガーされる継続的インテグレーション（CI）、およびバッチ変更が選択されました。
  • スケジュール：スケジュールされたトリガー。 ValidateShelveset：ユーザーが特定のTFVCシェルブセットのビルドを手動でキューに入れました。
  • CheckInShelveset：ゲートチェックイントリガー。
  • PullRequest：ビルドは、ビルドを必要とするGitブランチポリシーによってトリガーされました。
  • BuildCompletion：ビルドは別のビルドによってトリガーされました。
  • ResourceTrigger：ビルドはリソーストリガーによってトリガーされました。

次に、この変数を条件で使用できます。詳しくは こちら をご覧ください。

これを閉じると、展開用にjobという特別な種類のdeploymentがあることに注意してください。 yamlパイプラインを使用してアプリケーションをデプロイする場合は、これの使用を検討してください。

おまけの質問については、ビルドの設定を上書きできます。つまり、マスターおよびマスターブランチのみのトリガーを設定できます。ただし、他のブランチ（開発ブランチなど）のビルドを実行できます（たとえば、手動で実行）。それから何が起こりますか？新しく定義されたブランチに対してビルドが実行されます。最後に、これはビルド定義であり、自動ビルドの実行を制御するだけです。

1
Krzysztof Madej

2つの.ymlファイルが必要ですか？それぞれを定義している？すべての手順を繰り返すのはクールではないようです

一定期間調査した後、個人的には2つの.ymlビルドパイプラインが異なるファイル。

最もdirectの質問は、masterブランチとdevelopmentブランチのコードがリアルタイムで同期されないことです。 2つのブランチのコードが異なる場合、ビルドの結果は異なります。それらが同じパイプラインにある場合、ビルドが失敗したときにエラーが発生したブランチを手動で確認する必要があります。これはつらいことです。

別のdeep問題は、CI triggerおよびScheduled trigger 1つのyamlファイル内：

trigger: 
 branches:
    include:
      - master


schedules:
- cron: "* 10 * * *"
  always: true
  displayName: Daily midnight build (UTC 22:00)
  branches:
    include:
     - Development

これを実現するには、このyamlをDevelopmentブランチに設定する必要があります。マスターブランチのコードを変更すると、このパイプラインがトリガーされます。 ただし、Developmentブランチでコードをビルドするだけで、変更されたコードはマスターに含まれません。したがって、このCIトリガーは無意味になります。

各ブランチに同じファイルの異なるバージョンが必要ですか？これはある時点でマージされませんか？

個人的には、異なる名前の異なるyamlファイルを使用することをお勧めします。あなたが言ったように、同じファイルは後のブランチマージで不必要なリスクになりがちです。

私のボーナスの質問はもっと似ていました：異なるブランチに異なるバージョンのビルドパイプラインを保持するとしますか？プッシュして開発するたびに開発ブランチをビルドしたい場合、このトリガーをyamlファイルのマスターブランチバージョンで定義できますか？

答えはイエスです。 yamlファイルのmasterブランチバージョンで簡単な構文を使用してCIトリガーを設定できます。

trigger: 
 branches:
    include:
      - master
      - Development

この設定では、ブランチを開発するためにプッシュするたびに、yamlファイルのマスターブランチバージョンで定義されたビルドがトリガーされます。

注：おまけの質問では、CIトリガーを上に設定すると、devブランチでの継続的なコミットにより、パイプラインがビルドをトリガーします。場合によっては、Readmeファイルを変更するだけで、不要なビルドをトリガーするような変更を望まないことがあります。このような問題を解決する最善の方法は、PRトリガーを使用することです。 。

お役に立てれば。

1
Leo Liu-MSFT