はじめに

相変わらずパイプラインを回しています、なむゆです。
今回は、Azure Pipeline でパイプライン作成時に遭遇したパイプラインの実行条件のネタで一席打ちます。

パイプライン yaml のトリガーの話

Azure Pipeline とは Azure DevOps に含まれるサービスの一つで、CI/CD のためのパイプラインを作成し、実行できます。
Github 等のバージョン管理システムと連携することができ、設定さえしておけば Github 上のリポジトリにコードを push するだけで反射的にパイプラインを実行し、アプリケーションをビルドしたり(Continuous な Integration)、ビルドしたアプリを各種実行用の環境にデプロイしたり（Continuous な Delivery）することができる、CI/CD の概念を実現するためのサービスです。
Azure Pipeline を用いて CI/CD のためのパイプラインを実行する際にはそのパイプラインで行うことを指定するパイプライン yaml というものを書くのですが、その例や中身のざっくりした意味合いについては、こちらの記事で一つの例を解説しています。
今回は、この中では trigger: none とか pr:noneとなっている部分の話です。

これらの行は何を設定しているかというと、そのパイプラインが実行される条件です。
CI トリガー、PR トリガーと呼ばれています。
パイプラインを実行するためのトリガーにはほかにもいくつか種類があるのですが、今回はこれらの 2 つのトリガーで起きることを解説するため、他の種類のトリガーの解説については割愛します。

CI トリガー

まず、trigger: で始まるセクションは、CI トリガーというものを設定します。
これは、github のリポジトリ等の特定のブランチにコードが push された際、それをトリガーにしてパイプラインを回す設定です。
例えば ↓ のような書き方をします。

trigger:  
  branches:  
    include:  
    - '*'  
    exclude:  
    - feature/*

この例の意味合いとしては、「基本的にどのブランチにコードが push されてもこのパイプラインを実行するよ～（*は全ブランチを示す）、でも feature/下のブランチにはコードが push されてもパイプラインを回さないよ」というものになります。
include:の下にあるブランチ名の配列がそのブランチにコードが push された際にパイプラインを実行する条件で、excludeの下にあるブランチ名の配列は include の条件で判別した後でやっぱりパイプラインを実行しない場合を指定する条件になります。

簡略な書き方としては、コードの push でトリガーする対象のブランチだけを指定するものもあります。

trigger:  
- main  
- releases/*

上記の例では、main ブランチと release ブランチについてはコードが push されればパイプラインを実行しますが、他のブランチであれば実行しなくなります。

PR トリガー

次は、pr:で始まるセクションについてです。
こちらは PR トリガーというものを設定しています。
PR トリガーは、Github で PR が作成された際にパイプラインを実行するトリガーです。
例えば PR 作成時に単体テストを実行するなどといったことをするために使用します。

こちらは ↓ のような書き方をします。

pr:  
  branches:  
    include:  
    - main  
    - releases/*  
    exclude:  
    - releases/old*

意味合いとしては、PR 作成時にパイプラインが実行されるということ以外 CI トリガーのものと基本的に同じです。
こちらにも、CI トリガーと同じように簡略化した書き方があります。

pr:  
- main  
- releases/*

パイプラインのトリガーを設定しないとトリガーの対象が全てのブランチになる

Azure Pipeline のパイプライン yaml ではパイプラインの振る舞いを定義する様々な値を設定することができます。
その中のたいていのものは必要なければ設定を書かなければ何も起きず、パイプラインへの影響もありません。
しかし、その中で一部、何かしら値を設定しておかないと思っていたものと違う動作をする値があり、その例が CI トリガーと PR トリガーになります。

基本的にどの値も yaml の中に明示的に記述しなければ暗黙的にデフォルトの値が設定されるのですが、それが CI トリガーと PR トリガーでは以下のようになります。

trigger:  
  branches:  
    include:  
    - '*'  
pr:  
  branches:  
    include:  
    - '*'

つまり、デフォルトではどのブランチにコードが push されても、どのブランチにマージしようとする pr が作成されてもパイプラインが実行されることになります。

これだと、例えば何かしら常に手動でのみ回したいパイプラインがあった時、CI トリガーと PR トリガーが必要ないやと思って何も書かないでいると、どこかしらのブランチにコードが push され、PR が作られるたびに勝手にパイプラインが実行されるようになります。
例えば手動でしか回したくないような重くて長時間かかるような処理をパイプラインとして実行していた場合、コードの push のたびにパイプラインが実行され、Organization で確保していた Pipeline 用の Agent の枠を圧迫するようになってしまいます。
そういった事態は避けたいですよね。
なので、CI トリガーと PR トリガーは、使用しない場合は明示的に書いてやる必要があります。

trigger: none  
pr: none

このように書いておくと、コードの push や PR の作成をトリガーとしてパイプラインが実行されなくなるので、手動でのみ実行できるパイプラインになります。

おわりに

今回の記事では Azure Pipeline のトリガー設定は使用しない場合は明示的に使用しないことを記述しないと常に使用する状態になってしまうことを共有しました。
たぶんこの記事を読んでいる方は手動で回したりタイマーでトリガーするパイプラインが時々勝手に回っていることに悩んでいるのかなと思うので、その方向けの対処法を説明しました。
同じような問題を抱えている方の助けになれば幸いです。

参考

パイプラインをトリガーするイベントを指定する