Azure Pipelines · Artifacts · Checked November 6, 2026

Azure Pipelines: "Not found PathtoPublish": the publish step points at a path that is not there

The Publish build artifacts task (PublishBuildArtifacts@1) takes one folder or one file in PathtoPublish and checks that it exists before it uploads anything. When it does not, the task fails and prints the path it was given, after variables were expanded. That path usually tells you which case it is: a variable name the pipeline does not know (it stays as text), a wildcard (the input takes none), or a folder the build never wrote to (a Stack Overflow question on this message has been seen over 58,000 times).

When the publish step is part of a pull request's build validation, the required build stays failed until a run publishes: Azure DevOps Pull Requests, a plugin for JetBrains IDEs, lists the pull request's branch policies with their state in your IDE, and with Pro runs a failed build policy again once the pipeline is fixed. Get it on JetBrains Marketplace

What it looks like

• ##[error]Publishing build artifacts failed with an error: Not found PathtoPublish: D:\a\1\s\$(buildStagingDirectory)
• The part after PathtoPublish: is the path the task checked. A relative path is taken from the root of the repository, so D:\a\1\s\ (or /home/vsts/work/1/s/) in front means the input was relative, or started with a variable that was not expanded. D:\a\1\a (or /home/vsts/work/1/a) is $(Build.ArtifactStagingDirectory).
• If the folder exists but has no files, the step does not fail. It warns Directory '/home/vsts/work/1/a' is empty. Nothing will be added to build artifact 'drop'. and uploads nothing (a Stack Overflow question). The failure then shows up later, in the deploy: No package found with specified pattern.

Read the path in the message

• $(...) still in the path: the pipeline has no variable by that name, and a macro it does not know is left as written (Microsoft's page on variables). The question above used $(buildStagingDirectory); the folder is $(Build.ArtifactStagingDirectory), or $(Build.StagingDirectory), which is the same folder. For your own variables, check the spelling and that the variable is defined for this job.
• * or ** in the path: PathtoPublish takes no wildcards, as the task's own help says. $(Build.ArtifactStagingDirectory)/**/* fails as Not found (the same question). Publish the folder itself, or pick the files first with CopyFiles@2, whose Contents input does take patterns.
• A plain path that looks right: compare it, character by character, with a listing of the folder (next section). On Linux agents the case of each folder name counts.

List the folder before the publish step

• Put a step right before it: - script: find $(Build.SourcesDirectory) $(Build.ArtifactStagingDirectory) -maxdepth 4 on Linux, or Get-ChildItem $(Build.ArtifactStagingDirectory) -Recurse in a PowerShell step on Windows. You see what the earlier steps really wrote, and where.
• Or set the variable system.debug to true and run again; each task then logs the paths it used (an answer on the first question).

The build wrote somewhere else

• Build tools write to their own folders: Gradle to build/libs, Maven to target, dotnet build to bin/<configuration> under each project. Nothing lands in $(Build.ArtifactStagingDirectory) unless a step puts it there. Point PathtoPublish at the real output folder, or copy it first: CopyFiles@2 with Contents: '**/*.jar' and TargetFolder: $(Build.ArtifactStagingDirectory) is the accepted answer on a Gradle question.
• For .NET, give the output folder to the tool: arguments: --output $(Build.ArtifactStagingDirectory) on DotNetCoreCLI@2. Its outputDir input is only for command: pack, so on a build or publish it changes nothing; that is what happened in the question about the empty folder.
• A build step that failed or was skipped writes nothing. If the publish step still runs (condition: always() or succeededOrFailed()), Not found is only the second error; read the first failing step.
• Files from another job: each job can run on a different agent, and on Microsoft-hosted agents every job gets a fresh machine, so a later job does not have what an earlier job built. Publish in the job that built, and download the artifact where you need it.

Pipeline artifacts instead of build artifacts

• On Azure DevOps Services, Microsoft recommends Publish Pipeline Artifacts (PublishPipelineArtifact@1, or the publish: step) over this task for speed (the task's reference page). Its targetPath also has to exist, so switching does not fix a path that is not there; fix the path first.

Azure DevOps pull requests in IntelliJ IDEA and Rider

Azure DevOps Pull Requests, a plugin by Lesstep for JetBrains IDEs 2024.1 or later and Android Studio, reads the organization, project and repository from your git remote and lists the pull requests that wait for your review in an IDE tool window, on Azure DevOps Services and on Azure DevOps Server. It shows the branch policies of a pull request with their state, so a required build that has not passed is next to its pull request, and with Pro you run a failed or expired build policy again from there. The review inbox is free; voting, commenting, completing and creating are Pro, with a 30-day trial.

Get it on JetBrains Marketplace

Azure DevOps and Azure Pipelines are trademarks of Microsoft Corporation; GitHub is a trademark of GitHub, Inc.; IntelliJ IDEA and Rider are trademarks of JetBrains s.r.o. This page is not affiliated with or endorsed by Microsoft, GitHub, Inc. or JetBrains.

More: no template, or no parameters file · no zip where the deploy task looks · a Windows-only task on a Linux or macOS agent · a resource authorization issue · 日本語