Azure Pipelines の「Not found PathtoPublish」：公開のステップが、ないパスを指している
Publish build artifacts のタスク（PublishBuildArtifacts@1）は、PathtoPublish に1つのフォルダーか1つのファイルを受け取り、何かをアップロードする前にそれがあるかを確かめます。なければタスクは失敗し、変数を展開したあとの受け取ったパスを出します。たいていはそのパスで、どの場合かがわかります。パイプラインが知らない変数の名前（文字のまま残る）、ワイルドカード（この入力は受け付けない）、ビルドが書き込んでいないフォルダーのどれかです（このメッセージについての Stack Overflow の質問は5万8千回以上見られています）。
公開のステップがプルリクエストのビルド検証の中にあると、公開できる実行が通るまで必須のビルドは失敗のままです：JetBrains IDE のプラグイン Azure DevOps Pull Requests は、そのプルリクエストのブランチ ポリシーを状態つきで IDE に並べ、Pro ならパイプラインを直したあとで失敗したビルド ポリシーをそこからもう一度動かせます。JetBrains Marketplace で入れる
どう見えるか
##[error]Publishing build artifacts failed with an error: Not found PathtoPublish: D:\a\1\s\$(buildStagingDirectory)PathtoPublish:の後ろが、タスクが確かめたパスです。相対パスはリポジトリのルートから数えるので、前にD:\a\1\s\（または/home/vsts/work/1/s/）が付いていれば、入力が相対パスだったか、展開されなかった変数で始まっていたということです。D:\a\1\a（または/home/vsts/work/1/a）は$(Build.ArtifactStagingDirectory)です。- フォルダーはあるのにファイルが1つもないと、ステップは失敗しません。
Directory '/home/vsts/work/1/a' is empty. Nothing will be added to build artifact 'drop'.と警告して、何もアップロードしません（Stack Overflow の質問）。失敗はあとのデプロイで出ます：No package found with specified pattern。
メッセージのパスを読む
- パスに
$(...)が残っている：パイプラインにその名前の変数がなく、知らないマクロは書いたまま残ります（変数についての Microsoft のページ）。上の質問は$(buildStagingDirectory)と書いていました。フォルダーは$(Build.ArtifactStagingDirectory)か、同じフォルダーを指す$(Build.StagingDirectory)です。自分で作った変数なら、つづりと、そのジョブで定義されているかを確かめます。 - パスに
*や**がある：タスク自身の説明のとおり、PathtoPublish はワイルドカードを受け付けません。$(Build.ArtifactStagingDirectory)/**/*は Not found になります（同じ質問）。フォルダーそのものを公開するか、先にCopyFiles@2でファイルを選びます。こちらの Contents の入力はパターンを受け付けます。 - 普通のパスで、正しく見える：次の節のフォルダーの一覧と1文字ずつ比べます。Linux のエージェントでは、フォルダー名の大文字と小文字の違いも別のものになります。
公開のステップの前にフォルダーを一覧する
- すぐ前にステップを置きます。Linux なら
- script: find $(Build.SourcesDirectory) $(Build.ArtifactStagingDirectory) -maxdepth 4、Windows なら PowerShell のステップでGet-ChildItem $(Build.ArtifactStagingDirectory) -Recurseです。前のステップが実際に何をどこに書いたかが見えます。 - または変数
system.debugをtrueにしてもう一度動かします。それぞれのタスクが使ったパスをログに出します（最初の質問への回答）。
ビルドが別のところに書いた
- ビルドのツールはそれぞれ自分のフォルダーに書きます。Gradle は
build/libs、Maven はtarget、dotnet buildはプロジェクトごとのbin/<構成>です。どれかのステップが入れない限り、$(Build.ArtifactStagingDirectory)には何も入りません。PathtoPublish を実際の出力のフォルダーに向けるか、先にコピーします。CopyFiles@2にContents: '**/*.jar'とTargetFolder: $(Build.ArtifactStagingDirectory)を渡すのが、Gradle の質問で採用された回答です。 - .NET なら、出力のフォルダーをツールに渡します：
DotNetCoreCLI@2にarguments: --output $(Build.ArtifactStagingDirectory)。このタスクのoutputDirの入力はcommand: packのときだけのもので、build や publish では何も変わりません。空のフォルダーの質問で起きていたのはこれです。 - 失敗したかスキップされたビルドのステップは、何も書きません。それでも公開のステップが動くなら（
condition: always()やsucceededOrFailed()）、Not found は2つ目のエラーにすぎません。最初に失敗したステップを読みます。 - 別のジョブのファイル：ジョブごとに別のエージェントで動くことがあり、Microsoft ホストのエージェントではジョブごとに新しいマシンになります。前のジョブがビルドしたものは、あとのジョブにはありません。ビルドしたジョブの中で公開し、要るところでアーティファクトをダウンロードします。
ビルドのアーティファクトでなくパイプラインのアーティファクト
- Azure DevOps Services では、Microsoft は速さのためにこのタスクより Publish Pipeline Artifacts（
PublishPipelineArtifact@1、またはpublish:のステップ）を勧めています（タスクのリファレンスのページ）。こちらのtargetPathもあるパスでなければならないので、乗り換えてもないパスは直りません。先にパスを直します。
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 がない · Linux や macOS のエージェントに Windows 専用のタスク · リソースの承認の問題 · English