Azure Pipelines の「No package found with specified pattern」：デプロイのタスクが探すところに zip がない
デプロイのタスク（Azure App Service deploy・Azure Web App・Azure Functions）は、パッケージをパターンで探します。既定は $(System.DefaultWorkingDirectory)/**/*.zip で、何も当たらなければそこで止まります。zip が作られていないか、アーティファクトとして公開されていないか、デプロイのジョブが別のフォルダーに持っているかのどれかです。YAML のパイプラインでは最後がよくあります。ダウンロードしたアーティファクトは $(Pipeline.Workspace) に入り、そこは既定の作業ディレクトリの中ではありません（このメッセージについての Stack Overflow の質問は10万回以上見られています）。
デプロイがプルリクエストのビルド検証で動いていると、パッケージが見つかる実行が通るまで必須のビルドは失敗のままです：JetBrains IDE のプラグイン Azure DevOps Pull Requests は、そのプルリクエストのブランチ ポリシーを状態つきで IDE に並べ、Pro ならパイプラインを直したあとで失敗したビルド ポリシーをそこからもう一度動かせます。JetBrains Marketplace で入れる
どう見えるか
##[error]Error: No package found with specified pattern: D:\a\r1\a\**\*.zip<br/>Check if the package mentioned in the task is published as an artifact in the build or a previous stage and downloaded in the current job.- 中のパスが、タスクが探したところです。
D:\a\r1\aはクラシックのリリースの作業ディレクトリ、D:\a\1\s（または/home/vsts/work/1/s）は YAML のジョブのソースのフォルダーです。パターンはタスクの Package or folder の入力（package、AzureRmWebAppDeployment@4ではpackageForLinux）です。 - 近いメッセージの
More than one package matched with specified patternは、2つ以上の zip が当たったという意味です。デプロイする1つを名前で指定します（Stack Overflow の回答）。
まず、ジョブが持っているものを一覧する
- デプロイの前に、フォルダーを一覧するステップを置きます。Linux なら
- script: find $(Pipeline.Workspace) -name '*.zip'、Windows なら PowerShell のステップでGet-ChildItem $(Pipeline.Workspace) -Recurse -Filter *.zipです。どこにも zip がなければビルドの側、別のフォルダーにあればパターンの問題です。 - ビルドの実行の Summary のタブに、公開されたアーティファクトが出ます。何もなければ、リリースやデプロイのステージにはダウンロードするものがありません。
ビルドがパッケージを作っていない、または公開していない
- コンパイルするだけのビルドは zip を作りません。ASP.NET Core なら
DotNetCoreCLI@2をcommand: publishとpublishWebProjects: trueで足すと、Web のプロジェクトごとに zip にします。その出力をアーティファクトとして公開します。2つの Stack Overflow の質問（1つ目、2つ目）で採用された回答が、このステップです。 - ソースのフォルダーをまるごとステージングのフォルダーにコピーしても、パッケージにはなりません。デプロイのタスクに要るのは publish の出力です。
- いちばん読まれている回答は、ビルドの最後に抜けていた
PublishBuildArtifacts@1（またはパイプラインのアーティファクトのpublish:）を足しています。
YAML のデプロイのジョブが zip を別のところに持っている
- その実行のアーティファクトは
$(Pipeline.Workspace)/<アーティファクトの名前>にダウンロードされます。デプロイのジョブは自分でダウンロードしますが、後のステージの普通のジョブでは、先に- download: currentが要ります（パイプラインのアーティファクトについての Microsoft のページ）。 - YAML のジョブの
$(System.DefaultWorkingDirectory)はソースのフォルダーなので、既定のパターンは$(Pipeline.Workspace)/dropに届きません。パターンを zip のあるところにします：package: $(Pipeline.Workspace)/drop/**/*.zip。 - タスクはフォルダーも受け取ります。ビルドが zip ではなくフォルダーを公開した（
zipAfterPublish: false）なら、Package or folder を*.zipではなくそのフォルダーに向けます。
クラシックのリリース
- ビルドのパイプラインがリリースのアーティファクトになっていて、そのビルドがアーティファクトを公開している必要があります（Stack Overflow の回答）。リリースはそれを
$(System.DefaultWorkingDirectory)/<ソースの別名>/<アーティファクトの名前>にダウンロードします。 - Package or folder の横の ... のボタンでアーティファクトの中を見て、zip かフォルダーを選べば、実際にあるパスになります（別の回答は、アーティファクトの下のフォルダーを指定しています）。
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 のいずれとも提携しておらず、承認も受けていません。
ほかに：Failed to deploy web package の後ろのコード · 公開のステップが、ないパスを指している · Linux や macOS のエージェントに Windows 専用のタスク · リソースの承認の問題 · Microsoft ホストの並列ジョブがまだない · English