I created an Azure CI pipeline through Visual Studio 2019. The project target framework is .net core 3.1. However, during the NuGet Restore it fails.
I have .Net Core 2.2.2017 and 3.1.101 installed on my computer and my Visual Studio 2019 community version is 16.4. My environment variables paths are in place.
I also tried creating an app service manually that uses .net core 3.1 LTS stack but I still get the same error.
##[error]The nuget command failed with exit code(1) and error(C:\Program Files\dotnet\sdk\2.2.110\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.TargetFrameworkInference.targets(137,5):
error NETSDK1045: The current .NET SDK does not support targeting .NET Core 3.1. Either target .NET Core 2.2 or lower, or use a version of the .NET SDK that supports .NET Core 3.1.
This is the YAML file generated by Visual Studio
pool:
name: Hosted VS2017
demands:
- msbuild
- visualstudio
- vstest
steps:
- task: NuGetToolInstaller#1
displayName: 'Use NuGet 5.0.0'
inputs:
versionSpec: 5.0.0
- task: NuGetCommand#2
displayName: 'NuGet restore'
inputs:
restoreSolution: '$(Parameters.solution)'
- task: VSBuild#1
displayName: 'Build solution'
inputs:
solution: '$(Parameters.solution)'
msbuildArgs: '/p:DeployOnBuild=true /p:WebPublishMethod=Package /p:PackageAsSingleFile=true /p:SkipInvalidConfigurations=true /p:PackageLocation="$(build.artifactstagingdirectory)\\"'
platform: '$(BuildPlatform)'
configuration: '$(BuildConfiguration)'
- task: VSTest#2
displayName: 'Test Assemblies'
inputs:
testAssemblyVer2: |
**\$(BuildConfiguration)\*test*.dll
!**\obj\**
platform: '$(BuildPlatform)'
configuration: '$(BuildConfiguration)'
- task: PublishSymbols#1
displayName: 'Publish symbols path'
inputs:
SearchPattern: '**\bin\**\*.pdb'
continueOnError: true
- task: PublishBuildArtifacts#1
displayName: 'Publish Artifact'
inputs:
PathtoPublish: '$(build.artifactstagingdirectory)'
ArtifactName: '$(Parameters.ArtifactName)'
I believe, you do not need to install NuGetToolInstaller and vsbuild, you should firstly install DotNetCoreCLI after that you can use it. Here is manual how your yaml file should looks like.
Publishing by the IDE has no pain because it use the tools you have installed on your machine, in the pipeline you need to specify the toolin you gonna use and that is the pain.
For those who are not using the new YAML based pipeline but instead use classic editor on devops you might need to add dot net core add task and change from nuget restore to dotnet restore task
When I create a pipeline from the Azure Devops UI, my YAML looks like the below. It uses DotNetCoreCLI instead of VSBuild. Notice that it uses the Restore command instead of anything having to do with Nuget.
pool:
name: Azure Pipelines
#Your build pipeline references an undefined variable named ‘Parameters.RestoreBuildProjects’. Create or edit the build pipeline for this YAML file, define the variable on the Variables tab. See https://go.microsoft.com/fwlink/?linkid=865972
#Your build pipeline references an undefined variable named ‘Parameters.RestoreBuildProjects’. Create or edit the build pipeline for this YAML file, define the variable on the Variables tab. See https://go.microsoft.com/fwlink/?linkid=865972
#Your build pipeline references the ‘BuildConfiguration’ variable, which you’ve selected to be settable at queue time. Create or edit the build pipeline for this YAML file, define the variable on the Variables tab, and then select the option to make it settable at queue time. See https://go.microsoft.com/fwlink/?linkid=865971
#Your build pipeline references the ‘BuildConfiguration’ variable, which you’ve selected to be settable at queue time. Create or edit the build pipeline for this YAML file, define the variable on the Variables tab, and then select the option to make it settable at queue time. See https://go.microsoft.com/fwlink/?linkid=865971
steps:
- task: DotNetCoreCLI#2
displayName: Restore
inputs:
command: restore
projects: '$(Parameters.RestoreBuildProjects)'
- task: DotNetCoreCLI#2
displayName: Build
inputs:
projects: '$(Parameters.RestoreBuildProjects)'
arguments: '--configuration $(BuildConfiguration)'
- task: DotNetCoreCLI#2
displayName: Publish
inputs:
command: publish
publishWebProjects: True
arguments: '--configuration $(BuildConfiguration) --output $(build.artifactstagingdirectory)'
zipAfterPublish: True
- task: PublishBuildArtifacts#1
displayName: 'Publish Artifact'
inputs:
PathtoPublish: '$(build.artifactstagingdirectory)'
condition: succeededOrFailed()
Related
We made a deployment pipe and made it work on a Win machine. Then, we decided to attempt deploying it on Linux and created a new app service with Linux machine etc. Trying to reuse the previously working pipe, we made a few adaptations.
Partly, --runtime ubuntu.16.04-x64 (in the build step). Also, replacing the deployment step with the following.
- task: AzureRmWebAppDeployment#4
inputs:
ConnectionType: 'AzureRM'
azureSubscription: 'se-tyr-aux-az-con'
appType: 'webAppLinux'
WebAppName: 'app-aux-recorder'
packageForLinux: '$(System.DefaultWorkingDirectory)/**/*.zip'
RuntimeStack: 'DOTNETCORE|7.0'
StartupCommand: 'dotnet run'
Now, the content of the YAML is as follows.
pool:
vmImage: 'windows-latest'
variables:
solution: '**/*.sln'
project: '**/*.csproj'
buildPlatform: 'Any CPU'
buildConfiguration: 'Release'
steps:
- task: NuGetToolInstaller#1
- task: NuGetCommand#2
inputs:
restoreSolution: '$(solution)'
- task: DotNetCoreCLI#2
inputs:
command: 'build'
projects: '$(project)'
arguments: '/p:DeployOnBuild=true /p:target=package
/p:WebPublishMethod=Package /p:PackageAsSingleFile=true
/p:SkipInvalidConfigurations=true --runtime ubuntu.16.04-x64'
- task: AzureRmWebAppDeployment#4
inputs:
ConnectionType: 'AzureRM'
azureSubscription: 'se-tyr-aux-az-con'
appType: 'webAppLinux'
WebAppName: 'app-aux-recorder'
packageForLinux: '$(System.DefaultWorkingDirectory)/**/*.zip'
RuntimeStack: 'DOTNETCORE|7.0'
StartupCommand: 'dotnet run'
Each step reports green success. The application gets the default "some good stuff coming soon" page. However, swagger endpoint doesn't work nor does the controller method (status code 404 Not Found).
We're not sure if the application is running but fails to serve the request or if it's not been properly deployed. Checking the console (accessible during the deployment time), I can see a bunch of DLL's in the wwwroot directory's subfolders, including a file called Api (no file extension) that corresponds to the project's name.
Now sure how to investigate further. The documentation on YAMLs for Azure leaves a bit to ask and googling it gave me not much leads. We've used mostly this one and linked to it this one. They aren't of the highest quality.
Setting vmImage: 'ubuntu-latest' produced an error about the deployment not being able to find IIS instance, which suggests that we somehow made Azure think that we're targeting Windows with our deployment. However, I fail to see where we do so.
I suspect that you skipped some properties at the build step. I'm not familiar using this kind of arguments. Probably you need to pass the result of the build process to the deploy step, and, at the publish process, specify what files have to be deployed to you linux webapp.
This is the simplest way to achive it:
Deploy a .Net app (to an Azure WebApp)
steps:
- script: dotnet build --configuration $(buildConfiguration)
displayName: 'dotnet build $(buildConfiguration)'
- task: DotNetCoreCLI#2
inputs:
command: 'publish'
publishWebProjects: true
- task: AzureWebApp#1
inputs:
azureSubscription: '<Azure service connection>'
appType: 'webAppLinux'
appName: '<Name of web app>'
package: '$(System.DefaultWorkingDirectory)/**/*.zip'
As I like things clear, I would suggest to make it more explicit but at the same time more clear just doing a first and simple build step, and then a publish one to set the publish result (zip file) to a specific directory. Then, catch that zip within the AzureRmWebAppDeployment#4 step. Here, in this final step, you should use the zip result that is going to be used in the task.
This solution combines this steps:
Build project
Publish project (skip the PublishPipelineArtifact task)
Deploy to Azure webApp
Here goes an example:
variables:
solution: '**/*.sln'
project: '**/*.csproj'
buildPlatform: 'Any CPU'
buildConfiguration: 'Release'
azureSubscription: 'se-tyr-aux-az-con'
webAppName: 'app-aux-recorder'
steps:
- task: DotNetCoreCLI#2
displayName: Build
inputs:
command: build
projects: '$(project)'
arguments: '--configuration $(buildConfiguration)'
- task: DotNetCoreCLI#2
displayName: Publish
inputs:
command: publish
projects: '$(project)'
arguments: '--configuration $(buildConfiguration) -r ubuntu.16.04-x64 --self-contained true --output $(Build.ArtifactStagingDirectory)'
#this is equivalent to /p:PackageAsSingleFile=true
zipAfterPublish: true
- task: AzureRmWebAppDeployment#4
displayName: Api
inputs:
ConnectionType: 'AzureRM'
azureSubscription: '$(azureSubscription)'
appType: 'Web App on Linux'
WebAppName: '$(webAppName)'
packageForLinux: '$(Build.ArtifactStagingDirectory)/**/*.zip'
# $(Build.ArtifactStagingDirectory) is the path where de publish task set the zip
In other hand, you can create a multi-stage pipeline to deploy the Windows and linux app simultaniously.
This solution is an approach of the offical documentation:
Deploy to multiple web apps
Something similar to this:
stages:
- stage: BuildIt
jobs:
- job: BuildTheCode
pool:
vmImage: 'Ubuntu 16.04'
variables:
solution: '**/*.sln'
project: '**/*.csproj'
buildPlatform: 'Any CPU'
buildConfiguration: 'Release'
steps:
- task: DotNetCoreCLI#2
displayName: 'Build'
inputs:
command: build
projects: '$(project)'
arguments: '--configuration $(buildConfiguration)'
- task: DotNetCoreCLI#2
displayName: 'Publish'
inputs:
command: publish
projects: '**/*.csproj'
arguments: '--configuration $(buildConfiguration) --output $(Build.ArtifactStagingDirectory)'
#this is equivalent to /p:PackageAsSingleFile=true
zipAfterPublish: true
- task: PublishPipelineArtifact#1
inputs:
targetPath: '$(Build.ArtifactStagingDirectory)'
artifactName: '<artifact-name>'
- stage: Deployment
jobs:
- job: Publish to Windows
variables:
azureSubscription: 'se-tyr-aux-az-con'
webAppName: '<your-windows-webapp-name>'
steps:
# download the artifact from the previous job
- task: DownloadPipelineArtifact#2
inputs:
source: 'current'
artifact: 'drop'
path: '$(Pipeline.Workspace)'
- task: AzureRmWebAppDeployment
inputs:
ConnectionType: 'AzureRM'
azureSubscription: '$(azureSubscription)'
appType: 'webApp' #you can skip this, default value is webApp
WebAppName: '$(webAppName)'
package: '$(Pipeline.Workspace)/**/*.zip'
- job: Publish to Linux
variables:
azureSubscription: 'se-tyr-aux-az-con'
webAppName: '<your-linux-webapp-name>'
steps:
- download: 'current'
artifact: '<artifact-name>'
- task: AzureRmWebAppDeployment
inputs:
ConnectionType: 'AzureRM'
azureSubscription: '$(azureSubscription)'
appType: 'webAppLinux'
WebAppName: '$(webAppName)'
packageForLinux: '$(Pipeline.Workspace)/**/*.zip'
I have a DevOps team and have very less experience with C# and .NET.
I have code written by dev team.
This is the folder structure of the project:
Now when I built the software using visual studio community edition. It creates this folder structure.
Global.asax
Web.config
app_data
bin
Properties
But when i am running the build via Azure Devops Pipeline, then folder structure is changed.
- task: NuGetToolInstaller#1
displayName: Installing nuget
- task: NuGetCommand#2
displayName: nuget restore
inputs:
command: 'restore'
restoreSolution: '**/*.sln'
feedsToUse: config
nugetConfigPath: NuGet.config
- task: VSBuild#1
inputs:
solution: '**\*.sln'
msbuildArgs: '/p:OutDir=$(Build.ArtifactStagingDirectory)'
createLogFile: true
logFileVerbosity: diagnostic
name: BulidingSolutionTask
- task: PublishBuildArtifacts#1
displayName: 'Publish Build Artifacts'
inputs:
PathtoPublish: '$(Build.ArtifactStagingDirectory)'
ArtifactName: 'drop'
publishLocation: 'Container'
Below is folder structure.
_PublishedWebsites/Mainproject/Global.asax
_PublishedWebsites/Mainproject/Properties
_PublishedWebsites/Mainproject/Web.config
_PublishedWebsites/Mainproject/bin
_PublishedWebsites/webjob1/bin/FileSandDirecotriesOfWebJob
_PublishedWebsites/webjob2/bin/FileSandDirecotriesOfWebJob
Why am I getting extra folder created _PublishedWebsites/Mainproject and why Webjob1 and 2 has bin folder inside? Is it a development problem or build problem and how to fix it?
Your first screenshot is the structure of the "solution" in .NET, which is where your SLN file lives. Your second screenshot is of your "project" in .NET, which is where your CSPROJ file lives. If you only want to build the project but not the solution you would want to specify that in your DevOps tasks as **/XYZ.csproj (where "XYZ" is the name of the CSPROJ file in the Mainproject folder) rather then building the entire solution, which likely houses those other projects that you're getting in your build output.
Alternatively, you could leave the SLN build, and then use the following build args:
msbuildArgs: '/p:DeployOnBuild=true /p:WebPublishMethod=Package /p:PackageAsSingleFile=true /p:SkipInvalidConfigurations=true /p:PackageLocation="$(build.artifactStagingDirectory)"'
And then simply this for your publish:
- publish: '$(Build.ArtifactStagingDirectory)'
artifact: drop
This will put your individual projects into ZIP files that can then be deployed independently (i.e. if you were to want to deploy webjob1 or webjob2 later, you would have that option in your release pipeline).
I have an azure pipeline to build and publish a c# project to a docker image.
everything works just fine but today I wanted to add a unit test this pipeline.
so I added the task for it.
as follow:
- task: UseDotNet#2
inputs:
packageType: 'sdk'
version: '5.x'
- task: DotNetCoreCLI#2
displayName: 'DotNet - Restore'
inputs:
command: 'restore'
projects: $(project)
noCache: true
versioningScheme: 'off'
vstsFeed: 'feed'
- task: DotNetCoreCLI#2
displayName: "Run unit tests - $(Build.BuildNumber)"
inputs:
command: 'test'
arguments: '--no-build --configuration $(Build.BuildNumber)'
projects: 'path/to/Tests.csproj'
publishtestResults: true
- task: DotNetCoreCLI#2
name: 'DotnetPublish'
displayName: 'dotnet - Publish'
inputs:
command: 'publish'
projects: $(project)
arguments: '-o publish/projectapi -c release'
modifyOutputPath: false
zipAfterPublish: false
publishWebProjects: false
- task: Docker#2
name: 'dockerBuildAndPush'
displayName: 'docker - Build & Push'
inputs:
repository: $(imageRepository)
Dockerfile: $(dockerfilePath)
containerRegistry: ${{ variables.dockerRegistryServiceConnection }}
buildContext: ${{ variables.buildContext }}
tags: |
$(Build.BuildNumber)
latest
when I run the pipeline, on the test task, it take less than 2 second and it returns
##[warning]No test result files were found.
and if I head to the tests tab, I see the message that there are no tests to display.
Am I doing something wrong in my pipeline configuration?
thank you so much for any help
EDIT:
There are some update about this. The issue was related to the fact that I didn't have a build task for the test csproj.
When I implemented the task and run the pipeline. I got an error about a nuget package not found (private nuget). In my vsfeed in the devops panel, I can see that package exists, but for some reason the pipeline fails because it doesn't see that package.
Did this ever happened to anyone and knows a workaround?
Try removing the --no-build from the arguments. Nothing in the pipeline before it appears to run the build. You also may need to make sure that your dotnet restore command is restoring the packages for the test project. (I can't tell from if the restore for $(project) would or not)
my problem is that I have a project created in .net core 2.2, the problem is that I am trying to deploy it with azure pipelines but when using the dotnet restore it fails continuously and ends the construction.
The error it returns is the following:
2020-11-21T20:17:30.4639428Z ##[error]**Error: The process 'C:\hostedtoolcache\windows\dotnet\dotnet.exe' failed with exit code 1**
2020-11-21T20:17:30.4652823Z ##[error]**Packages failed to restore**
2020-11-21T20:17:30.4655465Z **Info: Azure Pipelines hosted agents have been updated to contain .Net Core 3.x (3.1) SDK/Runtime along with 2.1. Unless you have locked down a SDK version for your project(s), 3.x SDK might be picked up which might have breaking behavior as compared to previous versions.**
2020-11-21T20:17:30.4656214Z Some commonly encountered changes are:
2020-11-21T20:17:30.4657227Z If you're using `Publish` command with -o or --Output argument, you will see that the output folder is now being created at root directory rather than Project File's directory. 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
2020-11-21T20:17:30.4661682Z ##[section]Finishing: dotnet restore
I have tried to install version 2.2 to be used in the process before the restore, I have tried using the nuget.config and the global.json.I leave here the .yml that I have used to see if someone can give me a hand.
steps:
- task: UseDotNet#2
displayName: 'Use .NET Core sdk 2.2.x'
inputs:
version: 2.2.x
includePreviewVersions: true
performMultiLevelLookup: true
- task: DotNetCoreCLI#2
displayName: 'dotnet restore'
inputs:
command: restore
projects: '**/*.csproj'
- task: NuGetToolInstaller#0
displayName: 'Use NuGet 4.4.1'
inputs:
versionSpec: 4.4.1
checkLatest: true
- task: NuGetCommand#2
displayName: 'NuGet restore'
inputs:
restoreSolution: '$(Parameters.solution)'
- task: VSBuild#1
displayName: 'Build solution'
inputs:
solution: '$(Parameters.solution)'
msbuildArgs: '/p:DeployOnBuild=true /p:WebPublishMethod=Package /p:PackageAsSingleFile=true /p:SkipInvalidConfigurations=true /p:PackageLocation="$(build.artifactstagingdirectory)\\"'
platform: '$(BuildPlatform)'
configuration: '$(BuildConfiguration)'
- task: PublishSymbols#2
displayName: 'Publish symbols path'
inputs:
SearchPattern: '**\bin\**\*.pdb'
PublishSymbols: false
continueOnError: true
- task: PublishBuildArtifacts#1
displayName: 'Publish Artifact'
inputs:
PathtoPublish: '$(build.artifactstagingdirectory)'
ArtifactName: '$(Parameters.ArtifactName)'
condition: succeededOrFailed()
I've tested with a .net core 2.2 project using the following yaml file, and got successful result.
trigger:
- master
pool:
vmImage: 'windows-latest'
steps:
- task: UseDotNet#2
inputs:
version: '2.2.x'
includePreviewVersions: true
performMultiLevelLookup: true
- task: DotNetCoreCLI#2
inputs:
command: 'restore'
projects: '**/*.csproj'
In order to narrow down the issue, I'd like to suggest you:
Create a simple .net core 2.2 project and push to DevOps, create a pipeline for this project to see whether you can reproduce this issue.
Clone the project to local, and run dotnet restore command locally to see how's the result.
I come from GitLab and its .gitlab-ci.yml and I am experimenting with Azure DevOps multi stage pipelines but I am quite confused about how it works and what's the best strategy even after reading several documentation articles at https://learn.microsoft.com/en-us/azure/devops/pipelines/?view=azure-devops
Please allow me to ask several related questions for the basic scenario I'm trying, which is compile, run unit tests, pack a nuget Package for the whole solution (it could contain multiple projects/nuGet packages) and publish the package to a nuGet feed (if the branch is master, a release version, otherwise a pre-release version).
This is the repository I'm grabbing the code from: https://github.com/sasw-diego/sasw-test-support
It would generate only a nuGet package but I've got other multiproject solutions which should generate many nuGet packages
This is my azure-pipelines.yml so far:
trigger:
- master
- feature/*
pool:
vmImage: ubuntu-latest
variables:
NUGET_FOLDER_NAME: nupkgs
NUGET_REPOSITORY: https://whatever
PRERELEASE_SUFFIX: $(Build.BuildId)
PIPELINE_ARTIFACT_NAME: $(Build.BuildNumber)
stages:
- stage:
displayName: 'Build'
jobs:
- job: 'Build'
steps:
- task: NuGetAuthenticate#0
displayName: 'Authenticate in NuGet feed'
- script: dotnet restore --no-cache --force
displayName: 'Restore dependencies'
- script: dotnet build --configuration Release --no-restore
displayName: 'Build for Release'
- script: ls $(System.DefaultWorkingDirectory)
displayName: 'List content'
- publish: $(System.DefaultWorkingDirectory)
artifact: $(PIPELINE_ARTIFACT_NAME)
- stage:
displayName: 'Automated Tests'
condition: succeeded()
jobs:
- job:
displayName: 'Unit Tests'
steps:
- download: current
artifact: $(PIPELINE_ARTIFACT_NAME)
- script: ls -a
displayName: 'View'
- script: ls ./test
displayName: 'View test'
- script: ls ./test/Sasw.TestSupport.UnitTests
displayName: 'View folder'
- script: dotnet vstest test/*UnitTests/bin/Release/**/*UnitTests.dll
displayName: 'Run unit tests'
- stage:
displayName: 'NuGet Package'
condition: succeeded()
jobs:
- job:
displayName: 'Pack Preview Version'
condition: ne(variables['Build.SourceBranch'], 'refs/heads/master')
steps:
- script: dotnet pack *.sln --configuration Release --output $(NUGET_FOLDER_NAME)
displayName: 'Pack'
- job:
displayName: 'Pack Stable Version'
condition: eq(variables['Build.SourceBranch'], 'refs/heads/master')
steps:
- script: dotnet pack *.sln --configuration Release --output $(NUGET_FOLDER_NAME) --version-suffix $(PRERELEASE_SUFFIX) --include-source --include-symbols -p:SymbolPackageFormat=snupkg
displayName: 'Pack'
Which is the "best" strategy for a multistage? I see Azure DevOps pipelines have the concept of Stage > Jobs > Task but they all look similar to me. So I decide to divide the process in stages such as Build - AutomatedTests - NuGet Package - Publish
As you can see, it's a sequential process where each stage needs something from the previous one. The automated tests needs the built code (dll), the nuGet package needs also access to the built code, the publish needs access to the nupkg generated, etc. I don't know whether it's ok to follow this strategy or it's better to have a single stage with multiple jobs, or even a single job with multiple tasks. As I said I don't fully understand the benefit of having so many concepts and how do they fit in with my needs.
Is Azure multistage pipelines supposed to replace the old Build and Release as separate concepts? It makes sense to me to have the CI/CD in one place with a multistage approach and scriptable to make it versioned in a source control repository. But I still see the Release concept as a separate one currently on Azure DevOps. So probably I should use the azure pipelines yml up until the package "step" and then with Release go grab this nupkg and publish it onto some feed. Not sure what the benefit would be though.
I am having problems making the output of a stage as the input of the next one, and probably it's because I don't fully get it. In the yml above the build stage succeeds but the Automated Testing stage fails on its Run Unit Tests job with an error No test source files were specified. I verified this happens because there is no generated folder bin at all. It's seems strange since I am copying everything from the previous stage (and the previous stage generated bin folders with dll), but then the next stage, despite being able to download everything, it cannot find the tests.
This is the log for the stage that fails: https://gist.github.com/sasw-diego/df66eccf71bbfc044a4d72be96268c9a
It'd be very helpful if somebody spots what am I missing to be able to understand this process. Any link to clarify all these concepts would be much appreciated. Ta
PS: This is a similar generic CI/CD I had in GitLab to upload 1 or many nuGets to a feed:
https://gist.github.com/sasw-diego/bf46258cb1ad0aa5241e8d1866b53f48
UPDATE:
Thanks for the answer. I successfully created a CI/CD yml with multi-stage pipelines that restores, builds, executes tests, runs a container (e.g: an eventStore host) to run integration tests against it, and releases the nuGet in artifacts. So mission accomplished! I've separated it into different stages and jobs to probe some points
trigger:
- master
- feature/*
pool:
vmImage: ubuntu-18.04
variables:
- group: sasw-common-variables
- name: NUGET_FOLDER_NAME
value: nupkgs
- name: PIPELINE_ARTIFACT_NAME
value: $(Build.BuildNumber)
- name: PATH_PIPELINE_ARTIFACT_NAME
value: $(Pipeline.Workspace)/$(PIPELINE_ARTIFACT_NAME)
- name: NUGET_API_KEY
value: $(nuget-api-key)
- name: NUGET_FEED
value: $(nuget-feed)
- name: PRERELEASE_SUFFIX
value: $(nuget-prerelease-suffix)
resources:
containers:
- container: eventstore
image: eventstore/eventstore:release-5.0.2
ports:
- 1113:1113
env:
EVENTSTORE_INT_TCP_PORT: 1113
EVENTSTORE_EXT_TCP_PORT: 1113
EVENTSTORE_INT_HTTP_PORT: 2113
EVENTSTORE_EXT_HTTP_PORT: 2113
EVENTSTORE_EXT_HTTP_PREFIXES: http://*:2113/
stages:
- stage:
displayName: 'Build'
jobs:
- job: 'Build'
displayName: 'Build & Create nuGet Package'
services:
eventstore: eventstore
steps:
- task: NuGetAuthenticate#0
displayName: 'Authenticate in NuGet feed'
- script: dotnet restore --no-cache --force
displayName: 'Restore dependencies'
- script: dotnet build --configuration Release --no-restore
displayName: 'Build with Release Configuration'
- script: dotnet vstest test/*UnitTests/bin/Release/**/*UnitTests.dll
displayName: 'Run unit tests'
- script: dotnet vstest test/*IntegrationTests/bin/Release/**/*IntegrationTests.dll
displayName: 'Run integration tests'
- script: dotnet pack *.sln --configuration Release --output $(NUGET_FOLDER_NAME)
condition: and(succeeded(), eq(variables['Build.SourceBranch'], 'refs/heads/master'))
displayName: 'Create release nuGet'
- script: dotnet pack *.sln --configuration Release --output $(NUGET_FOLDER_NAME) --version-suffix $(PRERELEASE_SUFFIX) --include-source --include-symbols -p:SymbolPackageFormat=snupkg
condition: and(succeeded(), ne(variables['Build.SourceBranch'], 'refs/heads/master'))
displayName: 'Create pre-release nuGet'
- publish: $(System.DefaultWorkingDirectory)/$(NUGET_FOLDER_NAME)
artifact: $(PIPELINE_ARTIFACT_NAME)
displayName: 'Publish pipeline artifact'
- stage:
displayName: 'Release'
condition: succeeded()
jobs:
- job: 'Publish'
displayName: 'Publish nuGet Package'
steps:
- download: current
artifact: $(PIPELINE_ARTIFACT_NAME)
displayName: 'Download pipeline artifact'
- script: ls $(PATH_PIPELINE_ARTIFACT_NAME)
displayName: 'Display contents of downloaded articacts path'
- task: NuGetAuthenticate#0
displayName: 'Authenticate in NuGet feed'
- task: UseDotNet#2
displayName: 'Use latest .NET Core sdk 3.x'
inputs:
packageType: sdk
version: 3.x
includePreviewVersions: true
installationPath: $(Agent.ToolsDirectory)/dotnet
- script: dotnet nuget push $(PATH_PIPELINE_ARTIFACT_NAME)/**/*.nupkg --source $(NUGET_FEED) --api-key $(NUGET_API_KEY) --skip-duplicate
displayName: 'Uploads nuGet packages'
your whole build definition should be a single "stage". Those Build - AutomatedTests - NuGet Package - Publish are not stages, those are logical parts of the build.
probably sometime in the future that will\might happen
that is because you are using stages when you are not supposed to. each stage runs on a different agent. you should have a single stage and all the tasks should run inside that stage.