I am using Azure Devops for automatic build & deploy of asp.net core 3.1 web app to Azure App Service.
The problem is that it's deploying the app to strange folder. Instead of the wwwroot folder it is in
/home/site/wwwroot/Content/D_C/a/1/s/ExampleFolder/ExampleFolder2/ExampleFolder3/obj/Staging/netcoreapp3.1/PubTmp/Out
The app service is on Linux if it matters.
How I can just fix/change it to be in the main folder?
You should share your Pipeline with us, otherwise, we can't tell you what you have to change/fix.
However, here an example that uses the AzureWebApp#1 Task to deploy a .NET Core 3.1 application to an Azure Web App.
trigger:
branches:
include:
- master
stages:
- stage: Build
jobs:
- job: 'BuildArtifact'
pool:
vmImage: 'ubuntu-latest'
steps:
- task: UseDotNet#2
inputs:
packageType: sdk
version: 3.1.x
- task: DotNetCoreCLI#2
displayName: Build
inputs:
command: 'build'
projects: PATH/TO/YOUR/Project.csproj
arguments: --output $(System.DefaultWorkingDirectory)/publish_output --configuration Release
- task: ArchiveFiles#2
displayName: 'Archive files'
inputs:
rootFolderOrFile: '$(System.DefaultWorkingDirectory)/publish_output'
includeRootFolder: false
archiveType: zip
archiveFile: $(Build.ArtifactStagingDirectory)/$(Build.BuildId).zip
replaceExistingArchive: true
- publish: $(Build.ArtifactStagingDirectory)/$(Build.BuildId).zip
artifact: drop
- stage: Deploy
dependsOn: Build
condition: succeeded()
jobs:
- deployment: 'Deploy'
pool:
vmImage: 'ubuntu-latest'
environment: Development
strategy:
runOnce:
deploy:
steps:
- task: AzureWebApp#1
displayName: Azure Web App Deploy
inputs:
azureSubscription: YourAzureSubscription
appName: YourAppName
package: $(Pipeline.Workspace)/drop/$(Build.BuildId).zip
appType: webAppLinux
I solved my issue by creating new Pipeline which is using dotnet agents instead of Visual Studio build agents. When you are deploying to Linux App Service make sure to use CLI. You can see #martin-brandl answer for example pipeline.
You can also refer to this Devops SE question. The problem is similiar:
https://devops.stackexchange.com/questions/9598/azure-devops-artifact-zip-folder-structure-for-net-core-3-0-application
I'm looking this fact:
I have an ASP.NET Core 3.0 application for which I have a full CI/CD setup in Azure DevOps. The Application is hosted on a Ubuntu 18.04 server machine.
Therefore I can safely assume that you are developing ASP.NET Core 3.0 app to be hosted in Ubuntu. Any .NET Core 3.0 (or later) application means that you should rely on the dotnet build instead of using VSBuild.
Also you had stated that you will host the app on Ubuntu 18.x, then you should also run the build on Azure DevOps agent that runs on Ubuntu. This means you should only use dotnet build in DotNetCoreCLI#2 task, because VSBuild task only runs on Windows based agent, not Ubuntu and it is intended to compile .NET Framework and other platform other than .NET Core.
Please consult the official doc of DotNetCoreCLI#2 task at https://learn.microsoft.com/en-us/azure/devops/pipelines/tasks/build/dotnet-core-cli?view=azure-devops
After you use dotnet build, use dotnet publish to publish your artifact. It is much easier and it's also the best way to publish .NET Core apps.
I have sample usage of dotnet build and dotnet publish of this on my repo: https://github.com/eriawan/dotnetcore-cicd-samples/blob/master/yaml-samples/sample_pipelines_check.yml
Related
I am totally new to Azure, Pipelines, etc.
I am trying to create an App Service consisting of a web site and a WebJob (a background job that runs periodically). I want to build and deploy it using a Pipeline coded with a Yaml file.
I created a Visual Studio solution with a very simple ASP.Net Core web site (project "pipelines-dotnet-core"), and a simple .Net Core console program (project "WebJobsSDKSample").
I created the Yaml file to build, publish and deploy the web site to my App Service. This works fine and I can open the site in a browser.
I then extended the Yaml file to copy the output folder of the console program project to the publish folder of the web site, compress the result to a zip file and deploy that zip file. I understand that I have to copy the console program project output folder to /App_Data/jobs/triggered/app under the publish folder of the web site.
This new pipeline runs fine, and the web site still gets deployed correctly. However, when I open the WebJobs page of my App Service, it says "You haven't added any WebJobs".
The contents of my Yaml file is below. What do I need to change to correctly deploy the WebJob?
Also, if you could point me at clear examples of how to code a WebJob in a Yaml Pipeline file, that would be really helpful.
trigger:
- master
pool:
vmImage: 'ubuntu-latest'
variables:
buildConfiguration: 'Release'
steps:
- script: dotnet build --configuration $(buildConfiguration)
displayName: 'dotnet build $(buildConfiguration)'
- task: DotNetCoreCLI#2
inputs:
command: publish
publishWebProjects: True
arguments: '--configuration $(BuildConfiguration)'
zipAfterPublish: false
- task: CopyFiles#2
displayName: 'Copy Console App to WebJob Location'
inputs:
SourceFolder: WebJobsSDKSample/bin/Release/netcoreapp3.1
TargetFolder: pipelines-dotnet-core/bin/Release/netcoreapp2.2/publish/App_Data/jobs/triggered/app
- task: ArchiveFiles#2
displayName: 'Archive WebApp'
inputs:
rootFolderOrFile: pipelines-dotnet-core/bin/Release/netcoreapp2.2/publish
includeRootFolder: false
archiveFile: pipelines-dotnet-core/bin/Release/netcoreapp2.2/pipelines-dotnet-core.zip
- task: AzureWebApp#1
inputs:
azureSubscription: 'test connection 1'
appName: 'WebApplication120200310093243'
package: pipelines-dotnet-core/bin/Release/**/*.zip
I've an ASP.NET Core application I'm publishing on a dedicated server via Azure DevOps build/release pipelines.
I'm managing the application version number with the GitVersion task (gittools.gitversion.gitversion-task.GitVersion#4) in the YAML build.
The build step is something like:
- task: DotNetCoreCLI#2
displayName: 'dotnet build'
inputs:
command: custom
custom: build
workingDirectory: src/MyAppProjectFolder
arguments: '-p:Version=$(GitVersion.FullSemVer)'
And is correctly generating the .exe with the given FullSemVer (I'm inspecting the Azure agent work folder)
Then I've the publish step:
- task: DotNetCoreCLI#2
displayName: 'dotnet publish'
inputs:
command: publish
publishWebProjects: false
arguments: '--output $(build.artifactstagingdirectory) --no-restore --no-build'
workingDirectory: src/MyAppProjectFolder
For some reason the same .exe i found in the C:\agent_work\1\a\a.zip created by the publish DOESN'T have the correct version number, but the generic 1.0.0.
If I "emulate" the pipelines manually on the same server (with dotnet build and dotnet publish manually via powershell, same parameters) everything works as expected.
What's going on? Is there a way to ensure the application to keep the $(GitVersion.FullSemVer) version?
Note: I had to add
- task: UseDotNet#2
displayName: 'Use .Net Core sdk 2.1.x'
inputs:
packageType: sdk
version: 2.1.x
installationPath: $(Agent.ToolsDirectory)/dotnet
includePreviewVersions: true
in front of each NET Core task, as explained here, after the agents have been updated to .NET Core 3.0 (before these builds worked well).
Try adding -p:Version=$(GitVersion.FullSemVer) to your arguments for the publish step.
Today we experienced the following message in Azure Portal
WebJob cannot be added from portal if deployment form source control is configured.
We assume that this is a new feature hence the spelling is incorrect: 'deployment form source control' should be 'deployment from source control'.
I have no clue where to set a setting that solved this.
It has to be somewhere in DevOps we assume.
We solved it by not disconnecting a pipeline.
We solved it by implementing a seperate WebJob Build/Release Pipeline.
Here are the steps that worked for us:
In Azure Portal
Create a virtual application in your app service
In DevOps
In your build pipeline
Important Notice: add the following Argument: --output $(build.artifactstagingdirectory) to the build step.
In your release pipeline
This deploys the WebJob to the correct directory. In our case: $(System.DefaultWorkingDirectory)/_ms-reporting-webjob-dev-CI/drop
Having a look at the Kudo Console in our App Service the file location for our WebJob is:
Kudu Console
The workaround that worked for me was uploading the webjob directly via the Kudu Console.
Open the Kudu Console by selecting "Advanced Tool" --> "Go" in Your App Service on the Azure Portal.
Once on the Kudu portal open a "Debug Console" --> "CMD"
Go to the directory for your webjobs: "d:\home\site\wwwroot\app_data\jobs\continuous\{job name}" (https://github.com/projectkudu/kudu/wiki/WebJobs)
Then drag and drop the .zip file you prepared to upload your webjob (https://github.com/projectkudu/kudu/wiki/Kudu-console)
The job will now be listed on the Azure Portal and be started.
I used the following physical path in the Virtual Application and it solved it for us
site\wwwroot\App_Data\jobs\triggered\jobname
We had the same issue and noticed there was an old deployment pipeline connected to our web job in the Deployment Center blade. Disconnecting this solved the problem for us and we were able to manually deploy.
I used Kudu console to upload the webjobs
You can go to the path D:\home\site\wwwroot\App_Data\jobs\ and then upload the webjob folder here and then this shows up in your Webjobs portal as well
Don't go for the new CICD pipeline creation of this issue. Don't use chrome/safer while disconnecting the deployment center. Please use the latest IE or Microsoft Edge. it will allow the disconnect of the deployment center. I am able to do that in Microsoft Edge.
We had the same issue, and there was default configuration in deployment center for my web application, but we are not deploying the code from reposiotry, so we disabled that option. We are deploying web application from visual studio.
Currently the image showing disabled repository options in deployment center of the web application.
Probably because You set CI/CD for your web app deployment.
If you set your deployment with Azure Devops pipelines, and you are doing the yaml file approach, then maybe this is what you are looking for.
firstly you need to set the branch that you want to be triggred when a new commit has been pushed to it.
trigger:
branches:
include:
- refs/heads/staging
variables:
BuildConfiguration: 'Release'
pr: none # Disable pull request triggers.
To make our pipeline a little bit organized, We will work with stages, let's create our Build stage, here I am building a .Net app, you can replace the build task with the build you want.
stages:
- stage: 'Build'
jobs:
- job: 'Build'
pool:
vmImage: 'windows-latest' #The agent that will be used to start this stage
steps:
- task: DotNetCoreCLI#2
displayName: 'dotnet build'
inputs:
command: build
projects: 'MySuperApp/BackgroundService.csproj'
arguments: '--configuration $(BuildConfiguration)'
then I will run dotnet publish, that publishes the application and its dependencies to a folder for deployment to a hosting system.
and here comes the important part, when you create a webjob from azure portal, its files are stored under specific folder.
for Continuous webjobs, it will be stored under \site\wwwroot\app_data\Jobs\Continuous
and for Triggered webjobs it will be under \site\wwwroot\app_data\Jobs\Triggered
- task: DotNetCoreCLI#2
displayName: 'dotnet publish'
inputs:
command: 'publish'
arguments: '--configuration $(BuildConfiguration) --output $(Build.ArtifactStagingDirectory)/publish_output/App_Data/jobs/continuous/MySuperAppBGS'
projects: 'MySuperApp/BackgroundService.csproj'
publishWebProjects: false
zipAfterPublish: false
modifyOutputPath: false
for me I need to deploy a continuous webjob, as you can see in the arguments within inputs:
--output $(Build.ArtifactStagingDirectory)/publish_output/App_Data/jobs/continuous/MySuperAppBGS'
the dotnet publish will put the generated files under $(Build.ArtifactStagingDirectory)/publish_output/App_Data/jobs/continuous/MySuperAppBGS
then I will zip the content of $(Build.ArtifactStagingDirectory)/publish_output/ which is App_Data/jobs/continuous/MySuperAppBGS
- task: ArchiveFiles#2
displayName: 'Zip Published Files'
inputs:
rootFolderOrFile: '$(Build.ArtifactStagingDirectory)/publish_output'
includeRootFolder: false
archiveType: 'zip'
archiveFile: '$(Build.ArtifactStagingDirectory)/MySuperAppAPIBackgroundService.zip'
replaceExistingArchive: true
and publish the content of $(Build.ArtifactStagingDirectory) to drop artifact, which our zip file exist MySuperAppAPIBackgroundService.zip, in order to use it, in the next stage
- task: PublishBuildArtifacts#1
displayName: 'Publish Build artifacts'
inputs:
PathtoPublish: '$(Build.ArtifactStagingDirectory)'
ArtifactName: 'drop'
publishLocation: 'Container'
Here is the second stage, that will deploy our zip file to the web app service, then it will be unzipped leaving
App_Data/jobs/continuous/MySuperAppBGS/* under \site\wwwroot\
- stage: 'Deploy'
jobs:
- deployment: 'Deploy'
environment: 'MySuperAppAPI_BackGround_Staging_env' #just an env variable, that will be used later if you want, give it whatever name you like
strategy:
runOnce:
deploy:
steps:
- task: AzureWebApp#1
displayName: 'Deploy MySuperAppAPIBackgroundService.zip to MySuperAppAPI-Staging-BackgroundService'
inputs:
azureSubscription: 'Your Azure service connection'
appType: 'webApp'
appName: 'MySuperAppAPI-Staging-BackgroundService'
package: '$(Pipeline.Workspace)/drop/MySuperAppAPIBackgroundService.zip'
deploymentMethod: 'zipDeploy'
Note: in the second stage, I didn't call DownloadBuildArtifacts#0 task, because I used deploy: within - deployment: job that auto inject the Download artifact task, and to access the published Artifact from the previous stage, you use $(Pipeline.Workspace) following by the artifact name you provided, in my case it is $(Pipeline.Workspace)/drop
Hope I was clear, for any clarification don't hesitate to ask me.
I'm trying to use Azure Pipelines for the first time and have finally managed to configure my azure-pipelines.yml file so it runs tests and should automatically deploy if the tests pass. However, I'm receiving this error:
# ASP.NET Core
# Build and test ASP.NET Core projects targeting .NET Core.
# Add steps that run tests, create a NuGet package, deploy, and more:
# https://learn.microsoft.com/azure/devops/pipelines/languages/dotnet-core
trigger:
- master
pool:
vmImage: 'ubuntu-latest'
variables:
buildConfiguration: 'Release'
steps:
- script: dotnet build --configuration $(buildConfiguration)
displayName: 'dotnet build $(buildConfiguration)'
- task: DotNetCoreCLI#2
inputs:
command: test
projects: '**/*Tests/*.csproj'
arguments: '--configuration $(buildConfiguration)'
- task: DotNetCoreCLI#2
inputs:
command: publish
publishWebProjects: True
arguments: '--configuration $(BuildConfiguration) --output $(Build.ArtifactStagingDirectory)'
zipAfterPublish: True
- task: AzureRmWebAppDeployment#4
displayName: 'Azure App Service Deploy: ThermostatTestProject'
inputs:
azureSubscription: <mySubscription>
WebAppName: <myWebAppName>
packageForLinux: '$(build.artifactstagingdirectory)/**/*.zip'
- task: PublishSymbols#2
displayName: 'Publish symbols path'
inputs:
SearchPattern: '**\bin\**\*.pdb'
PublishSymbols: false
continueOnError: true
- task: PublishBuildArtifacts#1
displayName: 'Publish Artifact: drop'
inputs:
PathtoPublish: '$(build.artifactstagingdirectory)'
condition: succeededOrFailed()
I'm using a Mac - does anyone know how I can edit the yml file to make sure that it's Mac compatible and to get rid of this warning? I've been searching all day and cannot find a solution :(
Thank you
Trying to automate deployment with Azure Pipelines but warning due to not using Windows?
That because the task Index Sources & Publish Symbols task was written for Windows only not for Linux. When you execute this build pipeline on the agent ubuntu-latest, you will get that error.
So, this issue is not about Mac compatible but that task not compatible with Linux.
For this issue, MS replied:
Currently we don't support publishing symbols from a Linux machine.
What you could do is use SourceLink to index as usual as part of your
build and then have a job that runs on Windows to publish the symbols.
When we look at support *.snupkg packaging we will look to address the
Linux symbol publishing scenario.
Ticket here: https://github.com/MicrosoftDocs/vsts-docs/issues/3041
Besides, if you do not need to publish symbols from a Linux machine, you can disable this task.
Hope this helps.
I'm trying to implement continuous integration and continuous deployment to my DEV Azure App Service. I'm using the hosted agent on Visual Studio Team Services. The "Deploy Website to Azure" step on my Release definition keeps failing with the error "No package found with specified pattern". Any ideas?
"More than one package matched with specified pattern. Please restrain the search patern [sic]." error usually occurs when 2 or more packages were found by the task since you entered "xxx\*.zip" in "Package or Folder" setting of the task. So you just need to update it to specify the detailed package name. Similar question here: Deploy azure website and webjobs in same sln using VSO - Error - There can be only one.
And for you original issue, you can also fix it by creating a new build definition with "Visual Studio" selected on "Build" tab and "Azure WebApp" selected on "Deployment" tab. This will create a build definition with required arugments added.
Had the same problem few hours ago. This how I was able to resolve the issue:
Ensure MSBuild arguments in Build solution step are:
/p:DeployOnBuild=true /p:WebPublishMethod=Package /p:PackageAsSingleFile=true /p:SkipInvalidConfigurations=true /p:PackageLocation="$(build.artifactstagingdirectory)\"
Add step Azure App Service Deployment: ARM
Configure subscription and App Service Name
Package or Folder should be $(build.artifactstagingdirectory)\**\*.zip
Steps:
Azure App Service Deployment Configuration:
if you are using the default azure app service deployment task, add this to end of YAML file:
- task: DotNetCoreCLI#2
displayName: 'dotnet publish $(buildConfiguration)'
inputs:
command: publish
publishWebProjects: True
arguments: '--configuration $(buildConfiguration) --output $(Build.ArtifactStagingDirectory)'
zipAfterPublish: True
- task: PublishBuildArtifacts#1
displayName: 'publish artifacts'
I had the same issue and this worked for me:
# ASP.NET Core
# Build and test ASP.NET Core projects targeting .NET Core.
# Add steps that run tests, create a NuGet package, deploy, and more:
# https://learn.microsoft.com/azure/devops/pipelines/languages/dotnet-core
trigger:
- master
pool:
vmImage: 'ubuntu-latest'
variables:
buildConfiguration: 'Release'
steps:
- script: dotnet build --configuration $(buildConfiguration)
displayName: 'dotnet build $(buildConfiguration)'
- task: DotNetCoreCLI#2
displayName: 'dotnet publish $(buildConfiguration)'
inputs:
command: publish
publishWebProjects: True
arguments: '--configuration $(buildConfiguration) --output $(Build.ArtifactStagingDirectory)'
zipAfterPublish: True
- task: PublishBuildArtifacts#1
displayName: 'publish artifacts'
use the visual designer while creating build pipeline in azure devops,though your code sits at azure repos and github,
then select source
finally pick respective templates to your application
Make sure you didn't tick "Skip artifacts download"