Azure DevOps pipeline trigger issue message not going away - azure-devops

Our team is implementing an Azure DevOps testing pipeline. After our initial commit to create the pipeline .yml file this error message was displayed. After looking into it, I realized I forgot to include the trigger in the .yml. However after adding, it this error message hasn't gone away. The pipeline is working as expected though, we are just using a manual trigger which is shown below. The only listed issue is from the our original commit. Is there a way I can acknowledge this error to make it go away or am I potentially missing a different error that I just haven't noticed yet? Thanks for any help in advance, please let me know if I can provide any additional information.
Here are the error messages that I am seeing when I view the runs of that pipeline. I also included a screen shot of how I'm setting up my trigger.
Edit: As request I included the actual .yml file code below with slight naming modifications. We do have some custom plugins such as creating files for files that are untracked but still needed to be created. So you might need to remove those to test this.
trigger:
- none
pool:
name: myPool
demands:
- msbuild
- visualstudio
steps:
- task: NuGetToolInstaller#0
displayName: 'Use NuGet 4.4.1'
inputs:
versionSpec: 4.4.1
- task: NuGetCommand#2
displayName: 'NuGet restore'
inputs:
restoreSolution: '$(Parameters.solution)'
- task: eliostruyf.build-task.custom-build-task.file-creator#6
displayName: 'Create Connection Strings file'
inputs:
filepath: '$(System.DefaultWorkingDirectory)/ID_Web/config/ConnectionStrings.config'
filecontent: |
<connectionStrings>
</connectionStrings>
endWithNewLine: true
- task: eliostruyf.build-task.custom-build-task.file-creator#6
displayName: 'Create Developer Settings File'
inputs:
filepath: '$(System.DefaultWorkingDirectory)/ID_Web/config/developerAppSettings.config'
filecontent: |
<appSettings>
</appSettings>
endWithNewLine: true
- task: eliostruyf.build-task.custom-build-task.file-creator#6
condition: contains(variables['Agent.Name'], '1')
displayName: 'Create Developer Integration Setting for agent 1'
inputs:
filepath: '$(System.DefaultWorkingDirectory)/ID_Test/config/developerIntegrationSettings.config'
filecontent: |
<developerIntegrationSettings>
<add key="ModelsIntegrationTestDb" value="Models_IntegrationTest_BuildAgent1"/>
<add key="ErrorsIntegrationTestDb" value="Errors_IntegrationTest_BuildAgent1"/>
</developerIntegrationSettings>
endWithNewLine: true
- task: VisualStudioTestPlatformInstaller#1
displayName: 'Visual Studio Test Platform Installer'
inputs:
versionSelector: latestStable
# Build the 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)'
clean: true
# Run all unit tests in parallel
- task: VSTest#2
displayName: 'Run Unit Tests'
inputs:
testAssemblyVer2: |
**\*ID_Test*.dll
!**\*TestAdapter.dll
!**\obj\**
searchFolder: '$(System.DefaultWorkingDirectory)/ID_Test'
testFiltercriteria: '(FullyQualifiedName!~Integration & FullyQualifiedName!~Ioc)'
runOnlyImpactedTests: false
vsTestVersion: toolsInstaller
runSettingsFile: 'ID_Test/.runsettings'
runInParallel: true
runTestsInIsolation: false
codeCoverageEnabled: false
testRunTitle: 'Unit Tests'
platform: '$(BuildPlatform)'
configuration: '$(BuildConfiguration)'
diagnosticsEnabled: true
rerunFailedTests: true
# Run integration tests serially
- task: VSTest#2
displayName: 'Run Integration Tests'
inputs:
testAssemblyVer2: |
**\*ID_Test*.dll
!**\*TestAdapter.dll
!**\obj\**
searchFolder: '$(System.DefaultWorkingDirectory)/ID_Test'
testFiltercriteria: '(FullyQualifiedName~Integration | FullyQualifiedName~Ioc)'
runOnlyImpactedTests: false
vsTestVersion: toolsInstaller
runSettingsFile: 'ID_Test/.runsettings'
runTestsInIsolation: true
codeCoverageEnabled: false
testRunTitle: 'Integration Tests'
platform: '$(BuildPlatform)'
configuration: '$(BuildConfiguration)'
diagnosticsEnabled: true
rerunFailedTests: true
# Clean agent directories
- task: mspremier.PostBuildCleanup.PostBuildCleanup-task.PostBuildCleanup#3
displayName: 'Clean Agent Directories'
Edit (2): Included below is a screen shot of what I am using for trigger settings now, originally it was unchecked. Checking it doesn't seem to have any affect though.

I had the same and was about to curl up in a ball and cry when I found out the real issue. As the wonderful message is saying, it has absolutely nothing to do with trigger :)
I assume you created a new branch with your YAML file for testing purpose before merging it to master. So you need to setup your build to point to this branch because the file doesn't exist on your main branch.
Here the steps :
Edit your pipeline
Click the 3 dots on top right > Triggers
Click YAML tab > Get sources
Change the 'Default branch for manual and scheduled builds' to point to the branch where your .yml file is

So we gave up on this problem since it wasn't having any effect and we couldn't find the problem. After about a week or two it just stopped showing up. So I assume this was just some quirk with the Azure DevOps and not a problem with the pipeline itself.

According to your description, this issue looks more like an episodic issue. In YAML files, you don't have to include triggers. YAML pipelines are configured by default with a CI trigger on all branches. You can create a new pipeline and copy your YAML file to see if there are still any error messages.
Or, the issue could come from Classic UI triggers. On the pipeline editing page, select More actions-> Triggers.
Then you can check if there is anything illegal. If you want to use the trigger in the YAML file, leave the '
Override the YAML continuous integration trigger from here' check box off.

Related

CICD Yaml in Azure Devops for : dotnet6 project with some WebJobs into AppService in Azure

I have a dotnet6 project which I want to deploy on a AppService in Azure.
I am using Auzre Devops for my CICD and there I'm using a Yaml file for build and later deployment.
I have also some WebJobs that I want to deploy on the same AppService in the same slot.
The build process of my solution will provide a zip file with some files:
1- zip file
2- Parameters.xml
3- SetParameters.xml
4- readme.txt
5- and a deploy.cmd file which is a Batch file
This is the task for building a solution:
- task: VSBuild#1
inputs:
solution: 'Mydea/Mydea.sln'
msbuildArgs: '/p:DeployOnBuild=true /p:WebPublishMethod=Package /p:PackageAsSingleFile=true /p:SkipInvalidConfigurations=true /p:DesktopBuildPackageLocation="$(build.artifactstagingdirectory)\yourProject.zip" /p:DeployIisAppPath="Default Web Site"'
platform: '$(BuildPlatform)'
configuration: '$(BuildConfiguration)'
clean: true
Later in CD I use another command to deploy my zip file into the Azure like this:
- task: AzureRmWebAppDeployment#4
displayName: 'Deploy WebApp'
inputs:
ConnectionType: 'AzureRM'
azureSubscription: 'xxxx'
appType: 'webApp'
WebAppName: 'xxx'
deployToSlotOrASE: true
ResourceGroupName: 'xxxx'
SlotName: 'Test'
packageForLinux: '$(pipeline.workspace)/drop/WebApp.zip'
JSONFiles: '**/appsettings.json'
until here is everything fine.
But if I want to deploy some WebJob, it is different. I will not have a zip file with some batch, the only thing that I need here is a zip file which directing to the correct path:
App_Data/jobs/triggered/yourproject
later in the CD you need to call the same task in order to deploy your Webjobs.
Problem:
I can create 2 seperate zip file in the same artifact and later in CD, I need to call the deploy task. But the deploy task only can get one zip file.
If you calling the deploy task 2 times it will override it. that means you can have only your project deployed or your webjobs.
My idea was to combine the two zip files in the CI like this:
- task: VSBuild#1
inputs:
solution: 'xxx/xxx.sln'
msbuildArgs: '/p:DeployOnBuild=true /p:WebPublishMethod=Package /p:PackageAsSingleFile=true /p:SkipInvalidConfigurations=true /p:DesktopBuildPackageLocation="$(build.artifactstagingdirectory)\WebApp.zip" /p:DeployIisAppPath="Default Web Site"'
platform: '$(BuildPlatform)'
configuration: '$(BuildConfiguration)'
clean: true
- task: ExtractFiles#1
inputs:
archiveFilePatterns: '$(build.artifactstagingdirectory)\WebApp.zip'
destinationFolder: '$(Build.BinariesDirectory)/root'
cleanDestinationFolder: true
overwriteExistingFiles: true
- task: DotNetCoreCLI#2
displayName: 'publish Webjob Daily'
inputs:
command: 'publish'
publishWebProjects: false
projects: 'xxx/xxx.Webjob.Daily/xxx.Webjob.Daily.csproj'
arguments: '--output $(Build.BinariesDirectory)/root/App_Data/jobs/triggered/WebjobDaily'
zipAfterPublish: false
modifyOutputPath: false
- task: ArchiveFiles#2
displayName: 'Zip solution'
inputs:
rootFolderOrFile: '$(Build.BinariesDirectory)/root'
includeRootFolder: false
archiveType: 'zip'
archiveFile: '$(Build.ArtifactStagingDirectory)/WebApp.zip'
replaceExistingArchive: true
- task: PublishPipelineArtifact#1
displayName: Publish drop Artifact
inputs:
targetPath: '$(Build.ArtifactStagingDirectory)'
artifact: 'drop'
publishLocation: 'pipeline'
As you can see in this tasks, I combine the 2 zip files into one zip file.
notice that the zip file for the main solution has also some extra files with one batch file.
I tried to deploy this zip file in CD, the main project was successfully deployed but not the WebJobs.
If I deploy only the main project or only the WebJobs, it will be successfully done. but I need to deploy both of them togehter.
Now for me the last way is to create for my project another slot in the AppService. and deploy the main project on one Slot and the WebJobs on the other and this will work.
But this is not a clean solution.
I like to have them both in the same Slot.
I wouldn't combine the two artifacts into the same zip file. Reason being is how will platform know to split the zip file once it's extracted?
Doing a CI pipeline that builds the artifacts is certainly plausible, but why not have two different CD's that are triggered by the CI pipeline. Each separate CD will pull their respective artifact. Going this route does two things;
Doesn't overly complicate the CD pipeline with additional logic to handle two different artifacts, thereby keeping things clean and separated, and
If you ever decided to run your WebJob on a different app service (plan), you can easily change the deployment target.
I found the solution.
In the deployment you should have two separate zip files one for your WebApp and the other for your WebJobs, exactly like the code in my question.
In the deployment you should call the AzureRmWebAppDeployment#4 task two times, first for your WebApp and after that for your WebJobs.
But...
in order that the second task doesn't override the first task you should alter 2 other parameters; enableCustomDeployment to true and ExcludeFilesFromAppDataFlag to false.
- task: AzureRmWebAppDeployment#4
displayName: 'Deploy WebApp'
inputs:
ConnectionType: 'AzureRM'
azureSubscription: 'xxx'
appType: 'webApp'
WebAppName: 'xxx'
deployToSlotOrASE: true
ResourceGroupName: 'xxx'
SlotName: 'Test'
packageForLinux: '$(pipeline.workspace)/drop/WebApp.zip'
JSONFiles: '**/appsettings.json'
- task: AzureRmWebAppDeployment#4
displayName: 'Deploy Webjobs'
inputs:
ConnectionType: 'AzureRM'
azureSubscription: 'xxx'
appType: 'webApp'
WebAppName: 'xxx'
deployToSlotOrASE: true
ResourceGroupName: 'xxx'
SlotName: 'Test'
packageForLinux: '$(pipeline.workspace)/drop/Webjobs.zip'
JSONFiles: '**/appsettings.json'
enableCustomDeployment: true
ExcludeFilesFromAppDataFlag: false

Azure DevOps web.config transformation occurs in pipeline but is not copied to web root

This seems like an unusual issue, where the web.config transformation is actually occurring, but the result is not being copied to the web root.
Example line from web.config:
<compilation debug="true" targetFramework="4.8" />
Example line from web.release.config:
<compilation xdt:Transform="RemoveAttributes(debug)" />
Things I've checked:
Pipieline definitely has all files available, working folder contains:
web.config
web.Debug.config
web.Release.config
According to the pipeline logs, transformation does occur:
2022-07-27T21:12:39.8206023Z PreTransformWebConfig:
2022-07-27T21:12:39.8206775Z Found The following for Config tranformation:
2022-07-27T21:12:39.8207287Z web.config
2022-07-27T21:12:39.8207966Z Creating directory "D:\a\1\s\Integral.Web.AlbertSite\obj\Release\TransformWebConfig\transformed\".
2022-07-27T21:12:39.8249474Z Copying web.config to obj\Release\TransformWebConfig\original\web.config.
2022-07-27T21:12:39.8259591Z Copying D:\a\1\s\Integral.Web.AlbertSite\Web.Release.config to obj\Release\TransformWebConfig\assist\web.config.
2022-07-27T21:12:39.8293749Z TransformWebConfigCore:
2022-07-27T21:12:39.8294503Z Transforming Source File: D:\a\1\s\Integral.Web.AlbertSite\web.config
2022-07-27T21:12:39.8463519Z Applying Transform File: D:\a\1\s\Integral.Web.AlbertSite\Web.Release.config
2022-07-27T21:12:39.8893847Z Output File: obj\Release\TransformWebConfig\transformed\web.config
2022-07-27T21:12:39.9111483Z Transformation succeeded
2022-07-27T21:12:39.9149601Z PostTransformWebConfig:
2022-07-27T21:12:39.9150514Z Transformed web.config using D:\a\1\s\Integral.Web.AlbertSite\Web.Release.config into obj\Release\TransformWebConfig\transformed\web.config.
Viewed the file obj\Release\TransformWebConfig\transformed\web.config on the production server, and it is all correctly transformed.
So the transformation occurs, with the resulting correct web.config in obj\Release\TransformWebConfig\transformed\web.config on the server. However, the web.config file in the root folder remains untransformed.
It's like there should have been an extra step of copying the transformed file to the web root, which did not occur. Am I missing a flag or instruction in the YAML which fixes this?
The YAML is below:
trigger:
- deploy-production
pool:
vmImage: 'windows-2019'
variables:
solution: '**/*.sln'
buildPlatform: 'Any CPU'
buildConfiguration: 'Release'
steps:
# Install nuget and get solution dependencies.
- task: NuGetToolInstaller#1
- task: NuGetCommand#2
inputs:
restoreSolution: '$(solution)'
# Build solution.
- task: VSBuild#1
inputs:
solution: '$(solution)'
vsVersion: '16.0'
clean: false
msbuildArgs: '/p:DeployOnBuild=true /p:WebPublishMethod=Package /p:CreatePackageOnPublish=true /p:PackageAsSingleFile=true /p:SkipInvalidConfigurations=true /p:DeleteExistingFiles=False /p:publishUrl="$(build.artifactStagingDirectory)"'
platform: '$(buildPlatform)'
configuration: '$(buildConfiguration)'
# Deploy files to the staging slot.
- task: AzureRmWebAppDeployment#4
condition: succeeded()
inputs:
ConnectionType: 'AzureRM'
azureSubscription: 'Pay-As-You-Go (xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx)'
appType: 'webApp'
WebAppName: 'tulips-webapp-production'
deployToSlotOrASE: true
ResourceGroupName: 'Tulips-AusEast'
SlotName: 'staging'
packageForLinux: '$(Build.SourcesDirectory)/Tulips.WebApp'
enableCustomDeployment: true
DeploymentType: 'webDeploy'
TakeAppOfflineFlag: false
RenameFilesFlag: false
# Swap the staging slot into production.
- task: AzureAppServiceManage#0
condition: succeeded()
inputs:
azureSubscription: 'Pay-As-You-Go (xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx)'
Action: 'Swap Slots'
WebAppName: 'tulips-webapp-production'
ResourceGroupName: 'Tulips-AusEast'
SourceSlot: 'staging'
I'm thinking of simply adding a step to copy obj\Release\TransformWebConfig\transformed\web.config to the root, before the "Deploy files to the staging slot" step. This seems hacky though, so I'm wondering if I've missed something?
Look at where you're publishing your outputs to versus where you're deploying from. They are different locations.
/p:publishUrl="$(build.artifactStagingDirectory)"
versus
packageForLinux: '$(Build.SourcesDirectory)/Tulips.WebApp'
You're building a publish package, then completely ignoring that publish package and deploying something else.

Disable AzureFileCopy#2 pre job?

I am using Azure Devops Pipelines (YAML).
I have a AzureFileCopy#2 task which copies file from the source into a Storage Account. The Storage Account is created dynamically by an earlier ARM deploy task (the ARM task outputs the SA name which is then parsed into a variable for later consumption).
The AzureFileCopy#2 task works perfectly and copies all the files into the Storage Account. But, I notice in the run that the AzureFileCopy#2 task actually runs twice - once by me and once as a "pre-job". The pre-job of course fails with a warning that it can't reference the Storage Account (because by that stage I haven't created the variable).
Fortunately, it's only a warning but it is rather annoying to have that warning in every run.
I believe that pre-jobs can't be disabled (though I could drop that is a a feature enhancement) so is there a better way of handing this presumably common scenario?
Thanks in advance
EDIT: Obfuscated YAML added:
variables:
My.Configuration: 'Release'
My.SQLProject: 'contoso.api'
My.ARMProject: 'contoso.azure.templates'
My.IntEnvironment: 'i'
My.ResourceGroupNumber: 66
My.ArtifactLocation: 'drop'
# BUILD STAGES ARE HERE
- stage: 'Stage_Deploy'
displayName: 'Stage Deploy'
jobs:
- deployment: 'Job_Deploy'
pool:
vmImage: 'windows-2019'
displayName: 'Job Deploy'
environment: 'env1'
strategy:
runOnce:
deploy:
steps:
- download: none
- task: DownloadPipelineArtifact#2
displayName: 'Download Pipeline Artifacts from Drop'
inputs:
buildType: 'current'
targetPath: '$(Pipeline.Workspace)'
- task: AzureResourceManagerTemplateDeployment#3
displayName: 'ARM Deployment'
inputs:
deploymentScope: 'Resource Group'
azureResourceManagerConnection: 'CONTOSO CONNECTION'
subscriptionId: 'aaaaaaaa-0000-0000-00000-aaaaaaaaaaaaa'
action: 'Create Or Update Resource Group'
resourceGroupName: 'contoso-$(My.IntEnvironment)-eun-core-$(My.ResourceGroupNumber)-rg'
location: 'North Europe'
templateLocation: 'Linked artifact'
csmFile: '$(Pipeline.Workspace)/$(My.ArtifactLocation)/$(My.ARMProject)/azuredeploy.json'
csmParametersFile: '$(Pipeline.Workspace)/$(My.ArtifactLocation)/$(My.ARMProject)/azuredeploy.parameters.json'
overrideParameters: '-environment $(My.IntEnvironment)'
deploymentMode: 'Incremental'
deploymentOutputs: 'ARMOutput'
- task: PowerShell#2
condition: true
displayName: 'Parse ARM Template Outputs'
inputs:
targetType: filePath
filePath: '$(Pipeline.Workspace)/$(My.ArtifactLocation)/$(My.ARMProject)/Parse-ARMOutput.ps1'
arguments: '-ARMOutput ''$(ARMOutput)'''
- task: AzureFileCopy#2
condition: true
displayName: 'Copy Static Web Content to SA'
inputs:
SourcePath: '$(Pipeline.Workspace)/$(My.ArtifactLocation)'
azureSubscription: 'CONTOSO CONNECTION'
Destination: AzureBlob
storage: '$(ARM.AppDataStorageName)'
ContainerName: static
Then, when I run it, the following stages happen:
1. Initialize job
2. Pre-job: Copy Static Web Content to SA
It is this pre-job that, in the debugging shows this:
##[debug]StorageAccountRM=$(ARM.AppDataStorageName)
<other debug lines followed by...>
##[warning]Can\'t find loc string for key: StorageAccountDoesNotExist
Later on the task "Copy Static Web Content to SA" runs as a normal task and it runs fine.
Fortunately, it's only a warning but it is rather annoying to have
that warning in every run. I believe that pre-jobs can't be disabled
(though I could drop that is a a feature enhancement) so is there a
better way of handing this presumably common scenario?
Sorry but I'm afraid it's not supported to disable the warning. The warning occurs because it's by design.
(The source code of AzureFileCopyV2 task causes this behavior.)
More details:
We can find source of that task here. It contains one task.json file in which defines content like this:
"instanceNameFormat": "$(Destination) File Copy",
"prejobexecution": {
"Node": {
"target": "PreJobExecutionAzureFileCopy.js"
}
},
The task.json file describes the build or release task and is what the build/release system uses to render configuration options to the user and to know which scripts to execute at build/release time. Since the task.json has definition like prejobexecution, the predefined pre-job task will do the check about the inputs defined in PreJobExecutionAzureFileCopy.js file. Including the Storage Account.
So this is something by design of the code of AzureFileCopyV2 task, we can't disable the warning in pre-job task. If you do want to resolve that warning, you can consider using AzureFileCopyV1 in which doesn't define the prejobexecution, but this is not recommended. Compared with Version1, Version2 has some improvement and fixes some old issues.

how to convert classic build job to yaml build in AzureDevops

We have a working classic build job in azure Devops with an self hosted agent pool. But when we tried to convert this build job to yaml method, while executing no agents are getting assigned and its hanging. Could you please correct me here if i am doing something task.
Error
"All eligible agents are disabled or offline"
below is the converted yaml file from classic build - agent job
pool:
name: MYpool
demands: maven
#Your build pipeline references an undefined variable named ‘Parameters.mavenPOMFile’. 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
steps:
- task: Maven#3
displayName: 'Maven pom.xml'
inputs:
mavenPomFile: '$(Parameters.mavenPOMFile)'
- task: CopyFiles#2
displayName: 'Copy Files to: $(build.artifactstagingdirectory)'
inputs:
SourceFolder: '$(system.defaultworkingdirectory)'
Contents: '**/*.war'
TargetFolder: '$(build.artifactstagingdirectory)'
condition: succeededOrFailed()
- task: PublishBuildArtifacts#1
displayName: 'Publish Artifact: Root'
inputs:
PathtoPublish: '$(build.artifactstagingdirectory)'
ArtifactName: Root
condition: succeededOrFailed()
- task: CopyFiles#2
displayName: 'Copy wars to build directory'
inputs:
SourceFolder: '$(build.artifactstagingdirectory)/target'
TargetFolder: '/home/myadmin/builds/$(build.buildnumber)'
- task: CopyFiles#2
displayName: 'copying docker file to Build Directory'
inputs:
SourceFolder: Admin
TargetFolder: '/home/myadmin/builds/$(build.buildnumber)'
- bash: |
# Write your commands here
mv /home/myadmin/builds/$(build.buildnumber)/mypack0.0.1.war /home/myadmin/builds/$(build.buildnumber)/ROOT.war
displayName: 'Name war file Root.war'
- task: Docker#2
displayName: 'Build the docker image'
inputs:
repository: 'mycontainerregistry.azurecr.io/myservice'
command: build
Dockerfile: '/home/myadmin/builds/$(build.buildnumber)/Dockerfile'
tags: '$(Build.BuildNumber)-DEV'
- bash: |
# Write your commands here
docker login mycontainerregistry.azurecr.io
docker push mycontainerregistry.azurecr.io/myservice:$(Build.BuildNumber)-DEV
displayName: 'Push Docker Image'
- task: CopyFiles#2
displayName: 'Copy Deployment file'
inputs:
SourceFolder: /home/myadmin/kubernetes
TargetFolder: '/home/myadmin/builds/$(build.buildnumber)'
- task: qetza.replacetokens.replacetokens-task.replacetokens#3
displayName: 'Replace image in deployment file'
inputs:
rootDirectory: '/home/myadmin/builds/$(build.buildnumber)'
targetFiles: '**/*.yml'
In my previous answer, I said when I wait for nearly 20-30 mins, the interface of agent will prompt below message.
In fact, this is a process which upgrade the agent to latest version automatically.
Yes, when you using YAML with private agent, the agent version must be the latest one. No matter you add the demands or not.
For our system, the agent version is a implicit demand that your agent must satisfied with the latest one when you applying it in YAML.
If it is not satisfied, it will be blocked and the agent upgrade process will be forced to be performed automatically by system after some times.
So, to execute the private agent in YAML successfully, please upgrade the agent to latest one manually.
Since what my colleague and I talked are all private to microsoft in this ticket, sorry you could not get visible on this summary. So, here I take the screenshots about it, and you can refer to it: https://imgur.com/a/4OnzHp3
We are still working on why the system prompting so confusing message like: All eligible agents are disabled or offline. And, am trying to do some contribution to let this message more clear, for example: no agents meet demands: agent version xxx.

ReportGenerator missing Code Coverage tab (Azure DevOps Server 2019.0.1)

I follow the steps of Computing code coverage for a .NET Core project with Azure DevOps and Coverlet.
Build run like expected and every step ends successfully.
The Artefact-Explorer shown the uploaded report and In summary I get the Code Coverage result.
But I missing the Code Coverage tab next to Tests tab to take a look to the detailed report.
Configuration YAML:
- task: NuGetToolInstaller#0
displayName: 'Use NuGet 5.0.2'
inputs:
versionSpec: 5.0.2
checkLatest: true
- task: NuGetCommand#2
displayName: 'NuGet restore'
inputs:
restoreSolution: '$(Parameters.solution)'
- task: VSBuild#1
displayName: 'Projektmappe **\*.sln erstellen'
inputs:
solution: '$(Parameters.solution)'
platform: '$(BuildPlatform)'
configuration: '$(BuildConfiguration)'
- task: VisualStudioTestPlatformInstaller#1
displayName: 'Installer für Visual Studio Test-Plattform'
enabled: false
- task: VSTest#2
displayName: 'VsTest - testAssemblies'
inputs:
testAssemblyVer2: |
**\$(BuildConfiguration)\*test*.dll
!**\obj\**
codeCoverageEnabled: true
platform: '$(BuildPlatform)'
configuration: '$(BuildConfiguration)'
- powershell: ./'D:\AzureDevOpsData\Skripte\PowerShell\CodeCoverage.ps1'
displayName: 'PowerShell Test Code Coverage'
- task: Palmmedia.reportgenerator.reportgenerator-build-release-task.reportgenerator#4
displayName: ReportGenerator
inputs:
reports: coverage.cobertura.xml
targetdir: '$(Build.SourcesDirectory)/CodeCoverage'
- task: PublishCodeCoverageResults#1
displayName: 'Code Coverage veröffentlichen von $(Build.SourcesDirectory)/CodeCoverage/Cobertura.xml'
inputs:
codeCoverageTool: Cobertura
summaryFileLocation: '$(Build.SourcesDirectory)/CodeCoverage/Cobertura.xml'
reportDirectory: '$(Build.SourcesDirectory)/CodeCoverage'
The PowerShell Script contains:
#TEST CSPROJ
$csproj = "FrameworkA_Tests"
#SEARCH TEST CSPROJ.DLL
"`nrun tests:"
$unitTestFile = gci -Recurse | ?{ $_.FullName -like "*bin\*$csproj.dll" }
Write-Host "`$unitTestFile value: $unitTestFile"
#GET COVERLET.EXE
$coverlet = "D:\AzureDevOpsData\Tools\coverlet\coverlet.exe"
#RUN COVERLET.EXE
"calling $coverlet for $($unitTestFile.FullName)"
&$coverlet $unitTestFile.FullName --target "dotnet" --targetargs "vstest $($unitTestFile.FullName) --logger:trx" --format "cobertura"
Do I forget something?
Please try to enable "Boards" in the project settings:
This issue was fixed for Azure DevOps but may still exist in Azure DevOps Server.
See:
https://developercommunity.visualstudio.com/content/problem/385331/code-coverage-results-not-rendered-in-build-result.html
https://developercommunity.visualstudio.com/content/problem/398209/build-results-tab-code-coverage-does-not-show-up.html
ReportGenerator missing Code Coverage tab (Azure DevOps Server 2019.0.1)
This should be a known issue on the Developer Community:
Code coverage tab missing in Azure DevOps Server
MS team reply: A fix for this issue has been internally implemented and is being prepared for release.
As workaround, you can try the method provided by jingzhu yan:
you can add copy files and publish build results steps , then you can
download coverage result file from Artifacts.
Hope this helps.