I have a YAML pipeline which doesnt always obey the project build order
- job: Job_1
displayName: Agent job 1
pool:
vmImage: windows-2019
steps:
- task: UseDotNet#2
displayName: '.NET Core 3.1.404'
inputs:
version: '3.1.404'
packageType: sdk
- task: DotNetCoreCLI#2
enabled: true
displayName: dotnet test
continueOnError: falsefo
inputs:
command: test
projects: '**/*test/*.csproj'
arguments: --configuration $(buildConfiguration)
publishTestResults: true
This means that for some executions of the pipeline I get the error
Unable to find package NETStandard.Library with version (>= 2.0.3)
This occurs on a project that is not first to build in Visual Studio
Is there anyway of enforcing the build order? Or getting this package?
Paul
Unable to find package NETStandard.Library with version (>= 2.0.3). Is
there anyway of enforcing the build order? Or getting this package?
The problem is that the NETStandard.Library package was not found. I think it has nothing to do with the build order of the projects. NETStandard.Library is a nuget package, you can try to add a nuget restore task to the pipeline.
- task: NuGetCommand#2
inputs:
command: 'restore'
feedsToUse: 'config'
nugetConfigPath: 'nuget.config'
Is there anyway of enforcing the build order? Or getting this package?
You could build/test the specify project at first:
- task: DotNetCoreCLI#2
enabled: true
displayName: dotnet test
continueOnError: falsefo
inputs:
command: test
projects: '**/*test/TheSpecifyProject.csproj'
arguments: --configuration $(buildConfiguration)
publishTestResults: true
Then build/test other projects:
- task: DotNetCoreCLI#2
enabled: true
displayName: dotnet test
continueOnError: falsefo
inputs:
command: test
projects: '**/*test/*.csproj'
arguments: --configuration $(buildConfiguration)
publishTestResults: true
Or
- task: DotNetCoreCLI#2
enabled: true
displayName: dotnet test
continueOnError: falsefo
inputs:
command: test
projects: |
**/*test/*.csproj
!**/*test/TheSpecifyProject.csproj
arguments: --configuration $(buildConfiguration)
publishTestResults: true
Related
Is it possible to add a worker service to a already built .net core webapp?
The worker service is also .net core.
We build using a devops pipeline, and I Have tried this and it produces the extra file.
- task: DotNetCoreCLI#2
displayName: 'API Build'
inputs:
command: 'build'
projects: '**/Api.csproj'
arguments: '--configuration $(buildConfiguration)'
- task: DotNetCoreCLI#2
displayName : 'WebJob Builds'
inputs:
command: 'build'
projects: '**/WorkerService.csproj'
arguments: '--configuration $(BuildConfiguration) --self-contained -r win10-x64'
#----------------------------------------------------------
# Publish Artifacts
#----------------------------------------------------------
# Publish the artifact
- task: DotNetCoreCLI#2
displayName: 'Publish API Build'
inputs:
command: 'publish'
publishWebProjects: False
projects: '**/Api.csproj'
arguments: '--configuration $(BuildConfiguration) --output $(Build.ArtifactStagingDirectory)/Api'
zipAfterPublish: True
- task: DotNetCoreCLI#2
displayName : 'WebJobs Publish'
inputs:
command: 'publish'
publishWebProjects: false
projects: '**/WorkerService.csproj'
arguments: '--output $(Build.ArtifactStagingDirectory)/Api/App_Data/jobs/continuous/Worker'
zipAfterPublish: true
modifyOutputPath: false
- task: PublishBuildArtifacts#1
displayName: 'Release API Artifact'
inputs:
pathtoPublish: '$(Build.ArtifactStagingDirectory)/Api'
artifactName: 'WebApi'
I am not sure if this is the correct way, I need the worker to run as a job on the API webapp. How do I setup the release pipeline if this is correct, or how do I correct this and release it.
Basically, I have a pipeline that is pushing packages to a feed. I have it set to use environment variables to create a pre-release package version if the source is development branch. Otherwise, it should read the versioning from the .csproj file if the source branch is master. According to the logs, the correct steps are running. However, when I get to the push step, I notice in the logs that it's pushing a pre-release rather than the release to the feed despite the pre-release task not even running. What's going on and how can I fix this? Here are the tasks in question:
variables:
buildConfiguration: 'Release'
isDev: $[eq(variables['Build.SourceBranch'], 'refs/heads/development')]
isMain: $[eq(variables['Build.SourceBranch'], 'refs/heads/master')]
- task: DotNetCoreCLI#2
displayName: "Dotnet Pack"
condition: eq(variables.isMain, true)
inputs:
command: 'pack'
arguments: '--configuration $(buildConfiguration)'
packagesToPack: '**/*.csproj'
nobuild: true
versioningScheme: 'off'
- task: DotNetCoreCLI#2
displayName: "Dotnet Pack (pre-release)"
condition: eq(variables.isDev, true)
inputs:
command: 'pack'
arguments: '--configuration $(buildConfiguration)'
packagesToPack: '**/*.csproj'
nobuild: true
versioningScheme: byEnvVar
versionEnvVar: PackageVersion
- task: NuGetCommand#2
displayName: 'Nuget Push to Feed'
inputs:
command: 'push'
feedsToUse: 'select'
packagesToPush: '$(Build.ArtifactStagingDirectory)/**/*.nupkg;!$(Build.ArtifactStagingDirectory)/**/*.symbols.nupkg'
nuGetFeedType: 'internal'
publishVstsFeed: '*cleared*'
versioningScheme: 'off'
allowPackageConflicts: true
when I get to the push step, I notice in the logs that it's pushing a pre-release rather than the release to the feed despite the pre-release task not even running.
Based on my test, I could reproduce this issue when I run the pipeline with your Yaml Pipeline sample.
The root cause of this issue is the name of the environment variable PackageVersion.
When the environment variable name is PackageVersion, this issue will exist.
To solve this issue, you could change the environment variable name.
- task: DotNetCoreCLI#2
displayName: "Dotnet Pack (pre-release)"
condition: eq(variables.isDev, true)
inputs:
command: 'pack'
arguments: '--configuration $(buildConfiguration)'
packagesToPack: '**/*.csproj'
nobuild: true
versioningScheme: byEnvVar
versionEnvVar: Package1
Then it will work fine.
I have a relative simple test project under Azure DevOps and I want to generate code coverage.
This works... kinda. I get this:
I get the files I needed ( I think at least) But the tab is missing.
I have those three steps:
Do .NET test task
Install report generator
Run report generator to convert ( -reporttypes:HtmlInline_AzurePipelines;Cobertura")
publish result (s)
But the tab is not showing up? Any ideas?
- stage: Run_Unit_tests
jobs:
- job: 'Tests'
pool:
vmImage: 'windows-latest'
variables:
buildConfiguration: 'Release'
continueOnError: true
steps:
- task: DotNetCoreCLI#2
inputs:
command: custom
custom: tool
arguments: install --tool-path . dotnet-reportgenerator-globaltool
displayName: Install ReportGenerator tool
- task: DotNetCoreCLI#2
displayName: Test .NET
inputs:
command: test
projects: '**/*Test/*.csproj'
arguments: '--configuration $(buildConfiguration) --logger trx --collect:"XPlat Code Coverage"'
condition: succeededOrFailed()
- task: reportgenerator#4
inputs:
reports: '$(Agent.TempDirectory)\**\coverage.cobertura.xml'
targetdir: '$(Build.SourcesDirectory)\coverlet\reports'
verbosity: 'Verbose'
- task: PublishCodeCoverageResults#1
displayName: 'Publish code coverage'
inputs:
codeCoverageTool: Cobertura
summaryFileLocation: $(Build.SourcesDirectory)\coverlet\reports\Cobertura.xml
failIfCoverageEmpty: false
reportDirectory: $(Build.SourcesDirectory)\coverlet\reports\
I tried with code generator, without, enable code coverage variable or disable, tried with report generator and without...
I had the same problem, and just pressed F5 and it appeared!
It's mad, but it actually does it consistently.
It seems there's occasionally a bug in the devops front-end code?
You can try below yaml to publish code coverage.
First you need to make sure your project reference to nuget package coverlet.msbuild
<PackageReference Include="coverlet.msbuild" Version="2.5.1">
<PrivateAssets>all</PrivateAssets>
<IncludeAssets>runtime; build; native; contentfiles; analyzers</IncludeAssets>
</PackageReference>
Then in your dotnet test task to enable CollectCoverage
arguments: '/p:CollectCoverage=true /p:CoverletOutput=$(Build.SourcesDirectory)\TestResult\ /p:CoverletOutputFormat=cobertura'
Then in reportgenerator task specify the reports folder to the CoverletOutput folder reports: '$(Build.SourcesDirectory)\TestResult\**\coverage.cobertura.xml'
Please check below yaml for reference:
steps:
- task: UseDotNet#2
inputs:
version: 2.2.x
- task: DotNetCoreCLI#2
inputs:
command: restore
projects: '**\*.csproj'
- task: DotNetCoreCLI#2
inputs:
command: custom
custom: tool
arguments: install --tool-path . dotnet-reportgenerator-globaltool
displayName: Install ReportGenerator tool
- task: DotNetCoreCLI#2
displayName: Test .NET
inputs:
command: test
projects: '**\*Test*.csproj'
publishTestResults: false
arguments: '--configuration $(buildConfiguration) /p:CollectCoverage=true /p:CoverletOutput=$(Build.SourcesDirectory)\TestResult\ /p:CoverletOutputFormat=cobertura'
condition: succeededOrFailed()
- task: reportgenerator#4
inputs:
reports: '$(Build.SourcesDirectory)\TestResult\**\coverage.cobertura.xml'
targetdir: '$(Build.SourcesDirectory)\coverlet\reports'
verbosity: 'Verbose'
condition: succeededOrFailed()
- task: PublishCodeCoverageResults#1
displayName: 'Publish code coverage'
inputs:
codeCoverageTool: Cobertura
summaryFileLocation: $(Build.SourcesDirectory)\coverlet\reports\Cobertura.xml
failIfCoverageEmpty: false
reportDirectory: $(Build.SourcesDirectory)\coverlet\reports\
condition: succeededOrFailed()
You can also refer to this blog.
I had this issue too and tracked it down to having a mixture of VS Test and dotnet test tasks in my pipeline. Once I removed the VS Test task it all worked.
It seems the VS Test task uploads its own code coverage results and the combination of publishing cobertura results + this VS Test task confused Azure Devops.
I'm trying to get nUnit unit tests working with Xamarin.Forms. Everything works fine on my machine, but when I push to Azure and it goes into the build pipeline, I get the following error :
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 [/Users/runner/runners/2.164.6/work/1/s/TestProject1/TestProject1.csproj
When I remove the unit test project, the build is successful. I think the problem has something to do with the fact that Xamarin.Forms uses .Net Standard, while my unit test project is using .NET Core. How do I reconcile this? Specific advice or a pointer to a tutorial that goes over unit testing with Xamarin.Forms on Azure would be greatly appreciated. I'm really new to playing around with devops, so some kind of training track would be nice.
Also, here is my Azure Pipeline YAML file :
pool:
vmImage: 'macOS 10.13'
steps:
# To manually select a Xamarin SDK version on the Hosted macOS agent, enable this script with the SDK version you want to target
# https://go.microsoft.com/fwlink/?linkid=871629
- script: sudo $AGENT_HOMEDIRECTORY/scripts/select-xamarin-sdk.sh 5_4_1
displayName: 'Select Xamarin SDK version'
enabled: false
- task: NuGetToolInstaller#0
- task: NuGetCommand#2
inputs:
restoreSolution: '**/*.sln'
- task: XamariniOS#2
inputs:
solutionFile: '**/*.sln'
configuration: 'Release'
buildForSimulator: true
packageApp: false
Thanks!
As you already mentioned the unit test project is a .NET Core project and thus has to be executed with .NET Core. In a YAML build definition you can do this as follows:
- task: UseDotNet#2
displayName: 'Install .NET Core SDK'
inputs:
version: 3.1.x
performMultiLevelLookup: true
- task: DotNetCoreCLI#2
displayName: Build Tests
inputs:
command: 'build'
projects: '**\*Test.csproj'
arguments: '--configuration Release'
- task: DotNetCoreCLI#2
displayName: Run Tests
inputs:
command: 'test'
projects: '**\*Test.csproj'
arguments: '--configuration Release'
Here an example of a complete build pipeline definition to build a Xamarin Forms application with unit tests:
trigger:
branches:
include:
- '*'
pool:
vmImage: 'windows-2019'
steps:
- task: NuGetToolInstaller#0
displayName: Instal Nuget
inputs:
checkLatest: true
- task: NuGetCommand#2
displayName: Restore Nuget Packages
inputs:
restoreSolution: '**/*.sln'
- task: UseDotNet#2
displayName: 'Install .NET Core SDK'
inputs:
version: 3.1.x
performMultiLevelLookup: true
- task: DotNetCoreCLI#2
displayName: Build Tests
inputs:
command: 'build'
projects: '**\*Test.csproj'
arguments: '--configuration Release'
- task: DotNetCoreCLI#2
displayName: Run Tests
inputs:
command: 'test'
projects: '**\*Test.csproj'
arguments: '--configuration Release'
- task: XamarinAndroid#1
displayName: Build Android App
inputs:
projectFile: '**/*Android*.csproj'
outputDirectory: '$(build.binariesDirectory)/Release'
configuration: 'Release'
Guess the answer is a little too late for combodev1, but maybe it helps someone else who ends up here.
I have a simple build pipeline that triggers on my git commit and is working great.
Here is the .yaml for that process:
trigger:
- master
pool:
vmImage: 'ubuntu-latest'
variables:
buildConfiguration: 'Release'
steps:
- script: dotnet build --configuration $(buildConfiguration)
- task: ArchiveFiles#2
inputs:
rootFolderOrFile: '$(Build.BinariesDirectory)'
includeRootFolder: true
archiveType: 'zip'
archiveFile: '$(Build.ArtifactStagingDirectory)/$(Build.BuildId).zip'
replaceExistingArchive: true
displayName: 'dotnet build $(buildConfiguration)'
Then, I tried to make a Release build, but can't get the zip file across to my deploy step. The steps I follow are:
Publish build artifacts
Download build artifacts
Deploy web service
Here is my setup - Overall release pipeline:
Artifact Stage setup as follow:
Here is my 3 tasks in the Stage 1 (Deploy Stage):
Then the 3 tasks's properties:
And here is the error I'm getting, it is with regard to the artefact publish directory:
You should use dotnet publish to create your binaries. The step will also create a zip file. Then to publish the artefacts, use the PublishBuildArtifacts#1 Task. These steps should all be done within a build, not a release.
Here an example:
steps:
- script: dotnet build --configuration $(buildConfiguration)
displayName: 'dotnet build $(buildConfiguration)'
- task: DotNetCoreCLI#2
inputs:
command: 'publish'
publishWebProjects: false
projects: '**/*.csproj'
arguments: '-o /app'
- task: PublishBuildArtifacts#1
inputs:
PathtoPublish: '/app'
ArtifactName: 'drop'
publishLocation: 'Container'
Within the release, you don't need the Publish and Download Build Artefact step since the artefacts are already there (_ISOF). After you run the first Build, you can just select the zip file in the "Package or folder" dropdown.