Azure Pipelines の「Could not find any file matching the template file pattern」：テンプレートか、パラメーター ファイルがない
ARM テンプレートのデプロイのタスク（AzureResourceManagerTemplateDeployment@3、古い AzureResourceGroupDeployment@2 も同じ）は、Template の入力（csmFile）を $(System.DefaultWorkingDirectory) の下のパターンとして探し、Template parameters（csmParametersFile）が入っていればそれも同じように探します。どちらかでファイルが見つからないと、このメッセージで止まります。見た目より厄介な点が2つあります。テンプレートでもパラメーター ファイルでも同じ文が出ること、そしてどのパスを探したかを出さないことです。いちばん読まれている質問（Stack Overflow、2万7千回以上）では、テンプレートは見つかっていて、パラメーターの欄に値が書かれていました。
デプロイがプルリクエストのビルド検証で動いていると、ファイルが見つかる実行が通るまで必須のビルドは失敗のままです：JetBrains IDE のプラグイン Azure DevOps Pull Requests は、そのプルリクエストのブランチ ポリシーを状態つきで IDE に並べ、Pro ならパイプラインを直したあとで失敗したビルド ポリシーをそこからもう一度動かせます。JetBrains Marketplace で入れる
どう見えるか
##[error]Error: Could not find any file matching the template file pattern。後ろにパスは付きません。- タスクのコードは、この文を2つの場合に使っています。Template のファイルがないときと、Template parameters のファイルがないときです。テンプレートだけでなく、両方の入力を確かめます。
- 近いメッセージはもっと教えてくれます。
Found multiple files matching template file patternは2つ以上のファイルが当たったという意味で（1つに絞る）、Template file pattern matches a directory instead of a fileはパスがフォルダーで終わっているという意味です。 - Template location を URL of the file にすると、タスクはファイルをダウンロードし、パターンでは探しません。このメッセージは既定の Linked artifact のときのものです。
Template parameters の欄に値を書いた
- Template parameters が受け取るのは、
azuredeploy.parameters.jsonのようなパラメーター ファイルのパスです。値は Override template parameters に書きます：overrideParameters: '-storageName $(storageName) -location westeurope'。ファイルの欄に書いた値はファイル名として探され、何も当たらず、このメッセージになります（いちばん読まれている質問で採用された回答）。 - パラメーター ファイルがないなら、Template parameters は空にしておきます。空ならタスクは探しません。
相対パスは既定の作業ディレクトリから
- YAML のジョブでは、
$(System.DefaultWorkingDirectory)はリポジトリをチェックアウトしたフォルダー（D:\a\1\sまたは/home/vsts/work/1/s）です。パスにはリポジトリのルートからのフォルダーをすべて入れます：azuredeploy.jsonだけでなくcsmFile: infra/storage/azuredeploy.json（Stack Overflow の回答）。**/azuredeploy.jsonのようなパターンでも、当たるのが1つだけなら動きます。 - ファイルは、動いているブランチになければなりません。別のブランチで足したテンプレートはありません（別の回答がこれを指摘しています）。
- メッセージにパスが出ないので、タスクの前のステップでフォルダーを一覧します。Linux なら
- script: find $(System.DefaultWorkingDirectory) $(Pipeline.Workspace) -name '*.json' -not -path '*/node_modules/*'、Windows なら PowerShell のステップでGet-ChildItem $(Pipeline.Workspace) -Recurse -Filter *.jsonです。
YAML のデプロイのジョブ
- デプロイのジョブは、リポジトリを自分ではチェックアウトしません。テンプレートがリポジトリにあるなら、最初のステップに
- checkout: selfを置きます（デプロイのジョブについての Microsoft のページ。回答でも引かれています）。 - ビルドがテンプレートをアーティファクトとして公開したなら、デプロイのジョブはそれを
$(Pipeline.Workspace)/<アーティファクトの名前>にダウンロードします。そこは既定の作業ディレクトリの下ではありません。アーティファクトの名前まで含めたパスを書きます：csmFile: $(Pipeline.Workspace)/drop/infra/azuredeploy.json（複数ステージの質問への回答）。後のステージの普通のジョブでは、先に- download: currentが要ります。
クラシックのリリース
- ビルドがテンプレートを公開していて、そのビルドがリリースのアーティファクトになっている必要があります。ビルドの実行で公開されたアーティファクトを開き、テンプレートが入っているかを確かめます（Stack Overflow の回答）。
- Template と Template parameters の横の ... のボタンで、リンクしたアーティファクトからファイルを選べば、どちらも実際にあるパスになります。
IntelliJ IDEA と Rider で Azure DevOps のプルリクエスト
Azure DevOps Pull Requests は、Lesstep が作っている JetBrains IDE（2024.1 以降）と Android Studio のプラグインです。組織・プロジェクト・リポジトリを git のリモートから読み、自分のレビューを待っているプルリクエストを IDE のツールウィンドウに並べます。Azure DevOps Services でも Azure DevOps Server でも使えます。プルリクエストのブランチ ポリシーを状態つきで並べるので、まだ通っていない必須のビルドがそのプルリクエストの横に出て、Pro なら失敗したか期限が切れたビルド ポリシーをそこからもう一度動かせます。レビューの受信箱は無料、投票・コメント・完了・作成は Pro（30日間の無料試用つき）です。画面は日本語です。
Azure DevOps・Azure Pipelines は Microsoft Corporation の商標、GitHub は GitHub, Inc. の商標、IntelliJ IDEA・Rider は JetBrains s.r.o. の商標です。このページは Microsoft・GitHub, Inc.・JetBrains のいずれとも提携しておらず、承認も受けていません。
ほかに：公開のステップが、ないパスを指している · デプロイのタスクが探すところに zip がない · リソースの承認の問題 · English