Azure Pipelines: "No package found with specified pattern": no zip where the deploy task looks
The deploy task (Azure App Service deploy, Azure Web App, Azure Functions) looks for its package with a pattern, by default $(System.DefaultWorkingDirectory)/**/*.zip, and stops when nothing matches. Either no zip was made, the zip was never published as an artifact, or the deploy job has it in another folder. In a YAML pipeline the last is common: a downloaded artifact lands in $(Pipeline.Workspace), which is not inside the default working directory (a Stack Overflow question on this message has been seen over 100,000 times).
When the deploy runs in a pull request's build validation, the required build stays failed until a run finds the package: 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]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.- The path in it is where the task looked.
D:\a\r1\ais the working directory of a classic release;D:\a\1\s(or/home/vsts/work/1/s) is the sources folder of a YAML job. The pattern is the task's Package or folder input (package, orpackageForLinuxonAzureRmWebAppDeployment@4). - Its sibling,
More than one package matched with specified pattern, means two or more zips matched; name the one to deploy (a Stack Overflow answer).
First, list what the job has
- Put a step before the deploy that lists the folders:
- script: find $(Pipeline.Workspace) -name '*.zip'on Linux, orGet-ChildItem $(Pipeline.Workspace) -Recurse -Filter *.zipin a PowerShell step on Windows. No zip anywhere means the build side; a zip in another folder means the pattern. - In the build run, the Summary tab shows the published artifacts. If there are none, the release or the deploy stage has nothing to download.
The build made no package, or did not publish it
- A build that only compiles makes no zip. For ASP.NET Core, add
DotNetCoreCLI@2withcommand: publishandpublishWebProjects: true, which zips each web project, then publish the output as an artifact. The accepted answers on two Stack Overflow questions (one, two) are these steps. - Copying the whole source folder to the staging folder is not a package; the deploy task needs the published output.
- The most read answer adds the missing
PublishBuildArtifacts@1(orpublish:, the pipeline artifact) at the end of the build.
A YAML deploy job that has the zip somewhere else
- Artifacts of the current run are downloaded to
$(Pipeline.Workspace)/<artifact name>. A deployment job downloads them by itself; a regular job in a later stage needs- download: currentfirst (Microsoft's page on pipeline artifacts). $(System.DefaultWorkingDirectory)in a YAML job is the sources folder, so the default pattern does not reach$(Pipeline.Workspace)/drop. Set the pattern to where the zip is:package: $(Pipeline.Workspace)/drop/**/*.zip.- The task also takes a folder. If the build published a folder instead of a zip (
zipAfterPublish: false), point Package or folder at that folder rather than at*.zip.
A classic release
- The build pipeline has to be an artifact of the release, and the build has to have published artifacts (a Stack Overflow answer). The release downloads them to
$(System.DefaultWorkingDirectory)/<source alias>/<artifact name>. - The ... button next to Package or folder lets you browse the artifact and pick the zip or the folder, so the path is the one that exists (another answer sets it to the folder under the artifact).
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: what the code after Failed to deploy web package means · the publish step points at a path that is not there · a Windows-only task on a Linux or macOS agent · a resource authorization issue · no Microsoft-hosted parallel job yet · 日本語