Azure Pipelines: "Could not find any file matching the template file pattern": no template, or no parameters file
The ARM template deployment task (AzureResourceManagerTemplateDeployment@3, and the older AzureResourceGroupDeployment@2) looks up its Template input (csmFile) as a pattern under $(System.DefaultWorkingDirectory), then does the same for Template parameters (csmParametersFile) if that input is set. When either finds no file, it stops with this message. Two things make it harder than it looks: the message is the same for the template and for the parameters file, and it does not say which path it tried. The most read question on it (on Stack Overflow, seen over 27,000 times) had a template that was found and parameter values in the parameters field.
When the deployment runs in a pull request's build validation, the required build stays failed until a run finds the files: 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: Could not find any file matching the template file pattern, with no path after it.- The task's code uses these words for two cases: no file for Template, and no file for Template parameters. Check both inputs, not only the template.
- Its siblings say more:
Found multiple files matching template file patternmeans two or more files matched (name one), andTemplate file pattern matches a directory instead of a filemeans the path ends at a folder. - With Template location set to URL of the file, the task downloads the file and does not match a pattern, so this message is about Linked artifact, the default.
Parameter values in the Template parameters field
- Template parameters takes the path of a parameters file, such as
azuredeploy.parameters.json. Values go in Override template parameters:overrideParameters: '-storageName $(storageName) -location westeurope'. Values typed into the file field are matched as a file name, nothing matches, and you get this message (the accepted answer on the most read question). - If you have no parameters file, leave Template parameters empty; the task then skips it.
A relative path starts at the default working directory
- In a YAML job,
$(System.DefaultWorkingDirectory)is the folder the repository is checked out to (D:\a\1\sor/home/vsts/work/1/s). The path has to include every folder from the repository root:csmFile: infra/storage/azuredeploy.json, not justazuredeploy.json(a Stack Overflow answer). A pattern such as**/azuredeploy.jsonalso works, as long as only one file matches. - The file has to be in the branch that runs. A template added on another branch is not there (another answer points to this).
- The message gives no path, so list the folder in a step before the task:
- script: find $(System.DefaultWorkingDirectory) $(Pipeline.Workspace) -name '*.json' -not -path '*/node_modules/*'on Linux, orGet-ChildItem $(Pipeline.Workspace) -Recurse -Filter *.jsonin a PowerShell step on Windows.
A YAML deployment job
- A deployment job does not check out the repository by itself; add
- checkout: selfas its first step when the template is in the repository (Microsoft's page on deployment jobs, quoted in an answer). - If the build published the template as an artifact, a deployment job downloads it to
$(Pipeline.Workspace)/<artifact name>, which is not under the default working directory. Give the full path, artifact name included:csmFile: $(Pipeline.Workspace)/drop/infra/azuredeploy.json(answers on a multi-stage question). A regular job in a later stage needs- download: currentfirst.
A classic release
- The build has to have published the template, and that build has to be an artifact of the release. In the build run, open the published artifact and check the template is there (a Stack Overflow answer).
- Use the ... button next to Template and next to Template parameters to pick the files from the linked artifact, so each path is one that exists.
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: the publish step points at a path that is not there · no zip where the deploy task looks · a resource authorization issue · 日本語