I'm using Azure Dev Ops to run my build and release pipelines. I've got a build script that publishes my web code to an artifact folder (using .NET SDK projects), and I just need to push this code into my Azure app service. I've tried the "Azure app service deploy" and "Deploy code to app service" tasks in the release pipeline, giving it the publish settings file from my Azure instance and pointing to the folder with my code (since it says it takes zip or folder). On the console at this step, however, I get an error message of "No such deploying method exists."
I was able to get things pushed through FTP but I'd like to understand why the app service publish didn't work, as there are options (like deployment slots) that might be needed in the future. Is this a scenario where using the Azure resource manager connection would work better? Or does my build artifact need to be zipped after all? If it has to be zipped as a web deploy, is there a step to do this after a solution build, because I have to copy files into the artifact folder for transforms first, so I can't just do a comprehensive web build/zip.
I don't see details of your pipeline so I would share mine. I'm deploying zip package:
In Package or folder dialog I have:
I use YAML in my pipelines but it is easy to understand and follow if you want to have similar in classic pipelines:
trigger: none
pr: none
pool:
vmImage: 'windows-latest'
variables:
buildConfiguration: 'Release'
projectDirectory: 'app-service-deployment-to-slot-with-preview\hadar'
steps:
- script: dotnet build --configuration $(buildConfiguration)
displayName: 'dotnet build $(buildConfiguration)'
workingDirectory: $(projectDirectory)
- task: DotNetCoreCLI#2
displayName: Publish
inputs:
command: publish
publishWebProjects: false
projects: '$(projectDirectory)\hadar.csproj'
arguments: '--configuration $(buildConfiguration) --output $(Build.ArtifactStagingDirectory)'
zipAfterPublish: true
- task: CopyFiles#2
displayName: 'Copy configuration settings checks'
inputs:
contents: app-service-deployment-to-slot-with-preview\scripts\**
targetFolder: '$(Build.ArtifactStagingDirectory)\scripts'
flattenFolders: true
- task: PublishBuildArtifacts#1
displayName: 'Publish Artifacts'
Related
I've got a build pipe for an Azure Function using .Net Core 3.1.x. All the steps until the publishing are doing fine. I can get the publish step working by using script, but not through the yaml task. What am I missing?
Script (works)
- script: dotnet publish --configuration Release .\af-process-mds-vehicle-output-to-deviation\af-process-mds-vehicle-output-to-deviation.csproj
Task (does not work)
- task: DotNetCoreCLI#2
displayName: 'Publish Project'
inputs:
command: 'publish'
configuration: 'Release'
projects: '.\af-process-mds-vehicle-output-to-deviation\af-process-mds-vehicle-output-to-deviation.csproj'
zipAfterPublish: true
It doesn't find the project.
Here's the error message.
2021-10-29T05:21:44.3024816Z ##[section]Starting: dotnet publish
2021-10-29T05:21:44.3150367Z ==============================================================================
2021-10-29T05:21:44.3150726Z Task : .NET Core
2021-10-29T05:21:44.3151190Z Description : Build, test, package, or publish a dotnet application, or run a custom dotnet command
2021-10-29T05:21:44.3151475Z Version : 2.187.0
2021-10-29T05:21:44.3151733Z Author : Microsoft Corporation
2021-10-29T05:21:44.3152035Z Help : https://learn.microsoft.com/azure/devops/pipelines/tasks/build/dotnet-core-cli
2021-10-29T05:21:44.3152373Z ==============================================================================
2021-10-29T05:21:44.7797987Z [command]C:\Windows\system32\chcp.com 65001
2021-10-29T05:21:44.7903026Z Active code page: 65001
2021-10-29T05:21:44.7927221Z Info: .NET Core SDK/runtime 2.2 and 3.0 are now End of Life(EOL) and have been removed from all hosted agents. If you're using these SDK/runtimes on hosted agents, kindly upgrade to newer versions which are not EOL, or else use UseDotNet task to install the required version.
2021-10-29T05:21:44.8938257Z ##[error]No web project was found in the repository. Web projects are identified by presence of either a web.config file, wwwroot folder in the directory, or by the usage of Microsoft.Net.Web.Sdk in your project file. You can set Publish web projects property to false (publishWebProjects: false in yml) if your project doesn't follow this convention or if you want to publish projects other than web projects.
2021-10-29T05:21:44.9001249Z Info: Azure Pipelines hosted agents have been updated and now contain .Net 5.x SDK/Runtime along with the older .Net Core version which are currently lts. Unless you have locked down a SDK version for your project(s), 5.x SDK might be picked up which might have breaking behavior as compared to previous versions. You can learn more about the breaking changes here: https://learn.microsoft.com/en-us/dotnet/core/tools/ and https://learn.microsoft.com/en-us/dotnet/core/compatibility/ . To learn about more such changes and troubleshoot, refer here: https://learn.microsoft.com/en-us/azure/devops/pipelines/tasks/build/dotnet-core-cli?view=azure-devops#troubleshooting
2021-10-29T05:21:44.9003648Z ##[error]Project file(s) matching the specified pattern were not found.
2021-10-29T05:21:44.9182124Z ##[section]Finishing: dotnet publish
After the tips from the answer I got the pipe working. Here's the full working pipe. (Still don't know why it didn't work earlier.)
Working pipe:
name : af-vehicle-sync-to-deviation
## if there is a change is the deviation folder for the main branch. Then trigger.
trigger:
branches:
include:
- main
paths:
include:
- af-process-mds-vehicle-output-to-deviation/*
pool:
vmImage: 'windows-latest'
variables:
buildConfiguration: 'Release'
SolutionPath: '**\*.sln'
stages:
- stage: Build
displayName: Build solution
jobs:
- job: Build
displayName: Build and publish solution
steps:
- checkout: self
- task: NuGetToolInstaller#1
- task: NuGetCommand#2
inputs:
restoreSolution: $(SolutionPath)
- task: UseDotNet#2
inputs:
packageType: 'sdk'
version: '3.1.x'
displayName: 'Use .NET Core SDK 3.1.x'
- task: DotNetCoreCLI#2
inputs:
command: 'build'
configuration: $(buildConfiguration)
projects: '$(SolutionPath)'
displayName: 'Build solution'
- task: DotNetCoreCLI#2
displayName: 'Publish Project'
inputs:
command: 'publish'
configuration: 'Release'
projects: '**\*.csproj'
publishWebProjects: false
zipAfterPublish: true
arguments: '--output $(Build.ArtifactStagingDirectory)/$(buildConfiguration)'
- task: PublishBuildArtifacts#1
inputs:
PathtoPublish: '$(Build.ArtifactStagingDirectory)'
ArtifactName: 'drop'
publishLocation: 'Container'
You could use '**/*.csproj' but honestly, I would do something like this answer and add a script to list out all the files and folders recursively before this step that fails.
Assuming that you have a restore or build step before this publish you could add it after those, or just as the first step after your checkout one.
You can also inspect the logs of earlier steps to see the file path/s., instructions on doing this are available here.
Using $(System.DefaultWorkingDirectory) as your root is also recommended, rather than .\, so you would have '$(System.DefaultWorkingDirectory)\af-process-mds-vehicle-output-to-deviation...'.
Edit
If you look at the logs for your build step you will see entries like /home/vsts/work/1/s/XXX.YYY.ZZZ/XXX.YYY.ZZZ.csproj that refer to the different projects inside your solution. By default most commands will be run in $(System.DefaultWorkingDirectory) which would equate to /home/vsts/work/1/s/ in this instance, you can think of it as the root of your repository - there is more information on this structure here.
The error you were encountering is actually about the lack of a web project, rather than a path issue though, for the build step it is best practice to use the --output <output-directory-here> flag to output the compile files into a specific folder, that way you can easily publish that folder.
We created a build pipeline yaml for our blazor webassembly project that includes a publish task. For some reason only the wwwroot folder items get generated into the drop folder, and all the other binaries that are normally located outside of the wwwroot folder are not generated for some reason.
Here is part of the yaml file that builds and publishes. Is it setup incorrectly to get all the files generated and published, or is it just that it will only give us the static files being a webassembly project?
- script: dotnet build --configuration $(buildConfiguration)
displayName: 'dotnet build $(buildConfiguration)'
- task: DotNetCoreCLI#2
inputs:
command: 'publish'
publishWebProjects: true
projects: '**/*.csproj'
arguments: '--configuration $(buildConfiguration) --output $(build.artifactstagingdirectory)"'
zipAfterPublish: false
- task: PublishBuildArtifacts#1
displayName: 'Publish Artifact'
inputs:
PathtoPublish: '$(build.artifactstagingdirectory)'
condition: succeededOrFailed()
Also, since we are finding that Blazor webassembly has an issue using the Azure configuration settings for a web service, we are needing to have the publish process manipulate the web.config file so we can set the ASPNETCORE_ENVIRONMENT of the build and deploy. Everything I have found so far does not work when run in the DevOps build pipeline, as they are meant for dotnet scripts.
Does anyone know how this can be done? We have tried to add site /p:EnvironmentName=Development to the --output argument of the publish task, but it says it cannot run on multiple projects, even though we set the projects argument to just the one (it is not shown above as we put it back to normal for now).
Thank you,
Chris Calvert
Did you try this?
task: DotNetCoreCLI#2
displayName: Publish
inputs:
command: publish
publishWebProjects: True
arguments: '--configuration $(buildConfiguration) --output "$(build.artifactstagingdirectory)" /p:EnvironmentName=Development'
zipAfterPublish: True
I'm having trouble deploying a SSR Nuxt.js app from Azure DevOps Pipelines to Azure App Service.
Disclaimers:
✅I have setup an Azure App Service with a Linux container.
✅I have added this to nuxt.config.js
server: {
host: '0.0.0.0'
}
In Azure DevOps Pipelines I copy over these files after the build:
.nuxt/**
static/**
package.json
nuxt.config.js
then I zip them up as package.zip
in the logs it shows it as successfully zipping the files but when I unzip the package none of the .nuxt files are present. I'm also confused that for some reason in the package.zip it puts all the build files in a folder named simply a/
You can see in the photo that it's creating the 'a' folder at the top and that it looks like all the files are being added to the archive.
When I unzip the package.zip the only files that are in there are:
* package.json
* nuxt.config.js
* /static
this is what my YAML file looks like:
trigger:
- master
pool:
vmImage: 'ubuntu-latest'
steps:
- task: NodeTool#0
inputs:
versionSpec: '12.x'
displayName: 'Install Node.js'
- script: |
cd src/Web.Nuxt
npm install
npm run build
displayName: 'npm install and build'
- task: CopyFiles#2
inputs:
SourceFolder: '$(Build.SourcesDirectory)/src/Web.Nuxt'
Contents: |
.nuxt/**
static/**
package.json
nuxt.config.js
TargetFolder: '$(Build.ArtifactStagingDirectory)'
- task: ArchiveFiles#2
inputs:
rootFolderOrFile: '$(Build.ArtifactStagingDirectory)'
archiveType: 'zip'
archiveFile: '$(Build.ArtifactStagingDirectory)/package.zip'
replaceExistingArchive: true
- task: PublishBuildArtifacts#1
inputs:
PathtoPublish: '$(Build.ArtifactStagingDirectory)/package.zip'
ArtifactName: 'drop'
publishLocation: 'Container'
Any help would be greatly appreciated that can set me back on course to deploying a SSR Next.app with Azure DevOps Pipelines, Azure App Service, and a Nuxt SSR app. This has been tough to troubleshoot because in Azure DevOps Pipelines and Releases it says that everything was a success.
Nothing wrong with this process. The .nuxt folder is just hidden folder in Linux environment. It's hidden instead of missing ~
For Linux: The folder whose name starts with .(dot) is considered as one hidden folder. There's many discussions online about this behavior, you can try this one.
If you download that package.zip file and unzip it in Windows environment, you can easily find the .nuxt folder:
I'm facing a problem deploying an angular universal app in azure web service I followed this step https://stackoverflow.com/a/53616516/10979521 but a got an error says
##[error]Error: Publish using webdeploy options are supported only when using Windows agent.
I guess the issue occurs in creating an app service, in my app service settings
(
*publish (code)
*runtime stack (.NET Core 2.2)
*Operating System (Windows)
)
# Node.js with Angular
# Build a Node.js project that uses Angular.
# Add steps that analyze code, save build artifacts, deploy, and more:
# https://learn.microsoft.com/azure/devops/pipelines/languages/javascript
trigger:
- master
pool:
vmImage: 'ubuntu-latest'
steps:
- task: NodeTool#0
inputs:
versionSpec: '10.x'
displayName: 'Install Node.js'
- script: |
npm install -g #angular/cli
npm install
npm run build:ssr
displayName: 'build the project'
- task: CopyFiles#2
displayName: 'Copy dist files to staging'
inputs:
SourceFolder: '$(Build.SourcesDirectory)/dist'
TargetFolder: '$(Build.ArtifactStagingDirectory)/app/dist'
- task: CopyFiles#2
displayName: 'Copy server.js to the root'
inputs:
SourceFolder: '$(Build.ArtifactStagingDirectory)/app/dist'
Contents: server.js
TargetFolder: '$(Build.ArtifactStagingDirectory)/app'
- task: DeleteFiles#1
displayName: 'Delete the dist/server.js'
inputs:
SourceFolder: '$(Build.ArtifactStagingDirectory)/app/dist'
Contents: server.js
- task: AzureRmWebAppDeployment#3
displayName: 'Azure App Service Deploy: website'
inputs:
azureSubscription: 'my subscription'
WebAppName: 'my website'
Package: '$(Build.ArtifactStagingDirectory)/app'
GenerateWebConfig: true
WebConfigParameters: '-Handler iisnode -NodeStartFile server.js -appType node'
UseWebDeploy: true
RemoveAdditionalFilesFlag: true
Edit 2 (9/3/2020)
Microsoft is moving away from release pipelines.
"Classic Release Pipelines"
https://learn.microsoft.com/en-us/azure/devops/pipelines/release/?view=azure-devops
New "Pipelines"
https://learn.microsoft.com/en-us/azure/devops/pipelines/create-first-pipeline?view=azure-devops&tabs=java%2Cyaml%2Cbrowser%2Ctfs-2018-2
Edit:
I realized after I typed this up that maybe your problem is you have "UseWebDeploy: true" and maybe you can fix your problem by setting this to false. Below is a screenshot taken from the same task setup in a release pipeline.
I still think your best option is to remove the deploy task from your build pipeline as outlined below since build pipelines are not meant to be used in this way. But that is up to you.
Original Answer:
Remove this part from your build pipeline:
- task: AzureRmWebAppDeployment#3
displayName: 'Azure App Service Deploy: website'
inputs:
azureSubscription: 'my subscription'
WebAppName: 'my website'
Package: '$(Build.ArtifactStagingDirectory)/app'
GenerateWebConfig: true
WebConfigParameters: '-Handler iisnode -NodeStartFile server.js -appType node'
UseWebDeploy: true
RemoveAdditionalFilesFlag: true
Add a publish step to the end of you build.yml file. This will allow your release pipeline to pick up the artifacts from your build.
- task: PublishBuildArtifacts#1
Setup a release pipeline to deploy your build.
Create a new pipeline
Add the artifact from your build
Then add a stage (ie Dev, QA, Production)
Select "empty job"
Edit the stage and add tasks
Add the Azure App Service task
Update the version number on the Azure App Service Deploy to version 3 (the same one you are using in your yaml - AzureRmWebAppDeployment#3).
Fill in the values in the task the same way you have it in your yaml.
The default value for the "Package or folder" option probably isn't correct. You can use the 3 dots on the right to navigate and select the correct folder. If you click this and see nothing then this is most likely because you haven't kicked off a build yet with the above "PublishBuildArtifact#1" change.
Keep working your way down and expanding the options to find your other configuration settings.
If you are having trouble with anything you can verify the task is setup properly by scrolling to the top of the task and clicking "View YAML". Then you can compare to your original yaml.
Hopefully this helps.
I'm new to Azure DevOps; however, what I'm doing seems like it should be straightforward: I simply want to compile a project and publish to NuGet.org. I'm hitting that many barriers to doing it that I feel that I'm probably mis-using the tool.
I have a build which looks like this:
trigger:
- master
pool:
vmImage: 'windows-2019'
variables:
buildConfiguration: 'Release'
steps:
- script: dotnet build --configuration $(buildConfiguration) /property:Version=$(Build.BuildNumber)
displayName: 'dotnet build $(buildConfiguration)'
- task: PublishBuildArtifacts#1
inputs:
pathtoPublish: '$(Build.ArtifactStagingDirectory)'
artifactName: 'drop'
This successfully builds. However, I do get the following warning:
##[warning]Directory 'd:\a\1\a' is empty. Nothing will be added to build artifact 'drop'.
When I try to deploy, I'm getting errors - the latest of which is:
No files matched the search pattern.
In dotnet pack, here's the release step for pack:
steps:
- task: DotNetCoreCLI#2
displayName: 'dotnet pack'
inputs:
command: pack
packagesToPack: '$(System.DefaultWorkingDirectory)/name.project'
This is what's currently failing, but the next step is intended to publish to NuGet (for completeness - and incase there's an easier way to do all this):
steps:
- task: DotNetCoreCLI#2
displayName: 'dotnet pack'
inputs:
command: pack
packagesToPack: '$(System.DefaultWorkingDirectory)/name.project'
The release has an artifact, which I've set up as the output from the build (I think); however, I get the error from this:
No version is available for name.project or the latest version has
no artifacts to publish. Please check the source pipeline.
My understanding of how this should work in general is that the Build should hold the steps involved in producing the binaries, etc, whereas the Release should be any steps involved in deploying the built. So, I should be able to take a 'Build' and 'Release' it several times to multiple locations. I feel like this understanding is not in-keeping with the errors that I'm seeing.
Is my understanding correct?
What could I be doing wrong here and, more importantly, what are the methods of diagnosing issues with this?
Trying to publish a build to Nuget.org
For the first error, that because you are mising the Copy Files task before using the Publish Build Artifacts task.
Check the Publish Build Artifacts task, you can view this task is used to publish build artifacts to Azure Pipelines, TFS, or a file share.
But after build the project/solution, the output are stored on the build agent, rather than the artifacts. So we need to add a copy task before PublishBuildArtifacts to copy the files from output to the artifacts:
steps:
- task: CopyFiles#2
displayName: 'Copy Files to: $(build.artifactstagingdirectory)'
inputs:
SourceFolder: '$(system.defaultworkingdirectory)'
TargetFolder: '$(build.artifactstagingdirectory)'
enabled: false
For the second error, you should specify the project in the repos instead of System.DefaultWorkingDirectory, where is use to build the project, change the Path to csproj in the repos:
steps:
- task: DotNetCoreCLI#2
displayName: 'dotnet pack'
inputs:
command: pack
packagesToPack: NetCoreDemo/NetCoreDemo/NetCoreDemo.csproj
Hope this helps.
You man need to provide the --output argument for dotnet build. Add the following
--output $(Build.ArtifactStagingDirectory)
so the command should look something like this.
dotnet build --configuration $(buildConfiguration) /property:Version=$(Build.BuildNumber) --output $(Build.ArtifactStagingDirectory)
this will put the output into the Artifact Staging Directory (d:\a\1\a)
which will include the *.nupkg file.
I am assuming you are using the new CSProj format and you are supplying the properties for the NuGet package and have the <GeneratePackageOnBuild>true</GeneratePackageOnBuild> property already set. If so the *.nupkg file should be in the output directory that you define in the dotnet build command. Then you don't need to use dotnet pack. In the release definition you just need to use the NuGet task and use push command to push the package to your NuGet Feed.
Use this blog post as reference. It does not have the full details since its focusing only on few aspects of the entire process. but it should be helpful to get the build aspect correct.