I'm using and on-premise installation of Azure DevOps Server 2020 Update 1.2. I'm trying to configure the build pipeline to obtain the diff coverage indicators in the files tab of pull requests as shown in https://learn.microsoft.com/en-us/azure/devops/pipelines/test/codecoverage-for-pullrequests?view=azure-devops
I created two .Net Core projects one in Azure Devops Cloud and one in our on-premise server. The indicators appear in the cloud project but not on the on-premise hosted one. The only difference between both is that the on-premise linux build agent is based on RedHat instead of Ubuntu.
Are there requirements on the server or software that need to be installed on the server or the agent to get this coverage indicators working?
These are the relevant steps of my yaml pipeline:
- task: DotNetCoreCLI#2
displayName: 'dotnet restore task'
inputs:
command: 'restore'
feedsToUse: 'config'
nugetConfigPath: '$(Build.SourcesDirectory)/NuGet.config'
- task: DotNetCoreCLI#2
displayName: 'dotnet build $(buildConfiguration)'
inputs:
command: 'build'
arguments: '--configuration $(buildConfiguration)'
- task: DotNetCoreCLI#2
displayName: 'dotnet test $(buildConfiguration) v2'
inputs:
command: 'test'
projects: '**/*Test/*.csproj'
arguments: '--configuration $(buildConfiguration) --collect:"XPlat Code Coverage" --collect:"Code Coverage" -- DataCollectionRunSettings.DataCollectors.DataCollector.Configuration.Format=json,cobertura,lcov,teamcity,opencover,coverlet -- DataCollectionRunSettings.DataCollectors.DataCollector.Configuration.SplitCoverage="True"'
publishTestResults: true
This feature is currently not available for Azure DevOps Server 2020 Update 1.2.
Currently, we can only see the feature in the RTW Release Notes for Azure DevOps Server 2020 RC1.
For this, you may access this URL: https://aka.ms/AzDevOpsIdeas to submit any comments and proposals for future releases and implementations.
Related
I have an Azure DevOps pipeline step failing running the OWASP dependency check. I want to find what dependencies need to be updated.
The logs that are written during the dependency check pipeline step say:
[INFO] Writing report to: e:\vsts\a\7567\TestResults\dependency-check\dependency-check-report.html
I assume this dependency-check-report.html is where it will tell me what dependencies need to be updated. But I do not understand where this e:\vsts\a\7567\TestResults\ location is, as this step is being run in DevOps. Is this somewhere in DevOps? I cannot seem to find it anywhere. "Download logs" on the pipeline page doesn't seem to have it either.
where this e:\vsts\a\7567\TestResults\ location is
When you run the pipeline in Azure DevOps, this path represents the local path of the machine where the agent locates.
In your case, the agent is self-hosted agent. You go to the local machine where the agent locates and find the dependency-check-report.html in e:\vsts\a\7567\TestResults\dependency-check.
On the other hand, you can use the Publish Pipeline Artifacts task to upload the target file to Pipeline artifacts.
For example:
steps:
- task: dependency-check-build-task#6
displayName: 'Dependency Check'
inputs:
projectName: test
scanPath: test
continueOnError: true
- task: PublishPipelineArtifact#1
displayName: 'Publish Pipeline Artifact'
inputs:
targetPath: '$(Common.TestResultsDirectory)'
artifact: drop
Note: You need to set the continueOnError: true in OWASP dependency check task.
In this case, the dependency-check-report.html on agent machine will be uploaded to Azure Artifacts.
For example:
I’m using Gatling on my local machine. Now I need to move tests to our Azure DevOps server on prem version.
Anyone who has done this? I’ve not found a tutorial for this.
Since you are using the Azure Devops Server, you need to create a Self-hosted agent.
Then you can use your local script to run the gatling test.
Here is my maven gatling test example:
Yaml sample:
steps:
- task: Maven#3
displayName: 'Maven pom.xml'
- powershell: 'mvn gatling:test'
workingDirectory: '$(build.sourcesdirectory)'
displayName: 'PowerShell Script'
- task: PublishBuildArtifacts#1
displayName: 'Publish Artifact: drop'
inputs:
PathtoPublish: '$(Build.sourcesdirectory)'
Tried creating a single code coverage report for multiple test projects within a single build pipeline - Multiple stages within a single build.
- task: DotNetCoreCLI#2
displayName: Run Test
inputs:
command: 'test'
projects: |
$(FunctionProjectBase)/$(FunctionShortName1)/*.csproj
arguments: --configuration $(BuildConfiguration) --collect "XPlat Code coverage"
- task: PublishCodeCoverageResults#1
displayName: 'Publish code coverage report'
inputs:
codeCoverageTool: 'Cobertura'
summaryFileLocation: $(Build.SourcesDirectory)/**/coverage.cobertura.xml
- task: DotNetCoreCLI#2
displayName: Run Test
inputs:
command: 'test'
projects: |
$(FunctionProjectBase)/$(FunctionShortName2)/*.csproj
arguments: --configuration $(BuildConfiguration) --collect "XPlat Code coverage"
- task: PublishCodeCoverageResults#1
displayName: 'Publish code coverage report'
inputs:
codeCoverageTool: 'Cobertura'
summaryFileLocation: $(Build.SourcesDirectory)/**/coverage.cobertura.xml
But this is not generating code coverage report on "Code coverage tab" Azure DevOps. It only generates a downloadable file.
But this is not generating code coverage report on "Code coverage tab" Azure DevOps. It only generates a downloadable file.
This is a known issue on Azure devops. Now, we could only download the report, and could open it with Visual Studio.
Azure devops only support the download link for .coverage files currently. The white page you see is a UI glitch. This scenario is only supposed to render a download link to the coverage file.
Besides, this issue has been submitted in this earlier suggestion ticket linked here:
support vstest .coverage "code coverage" build results tab
This feature request is On Roadmap, I believe it will be released soon, you can vote and follow this thread to know its latest feedback.
Hope this helps.
How does Azure DevOps identify linked workitems during pipeline (Azure DevOps YAML)?
I believe it is supposed to get only the workitems linked to new commits (i.e. commits which were not included in a previous pipeline)
However, it sometimes seems to link all work items. But this does not always happen. I did not manage to identify the pattern yet. But I noticed that when I do a change in the pipeline YAML, it seems to trigger this behaviour that links all work items again (even if they where linked to a previous commit and not to newly included commits).
Updated to include additional information
This is my build pipeline YAML
name: 03.01.00$(Rev:.r)
pool:
name: Hosted VS2017
demands:
- msbuild
- visualstudio
- vstest
steps:
- checkout: self
clean: true
persistCredentials: true
- task: NuGetCommand#2
displayName: 'NuGet restore'
inputs:
restoreSolution: MySol/MySol.sln
- task: VSBuild#1
displayName: MySol/MySol.sln
inputs:
solution: MySol/MySol.sln
vsVersion: 15.0
- task: WorkItemUpdater#2
inputs:
workitemsSource: 'Build'
workItemType: 'Task,Bug'
updateAssignedTo: 'Never'
updateFields: 'Microsoft.VSTS.Build.IntegrationBuild,v$(Build.BuildNumber)'
- task: VSTest#2
displayName: 'VsTest - testAssemblies'
Pipeline settings:
Processing od new run requests: Enabled
Automatically link work items included in this run: checked & dev branch selected
Triggers:
Override the YAML continuous integration trigger from here: checked
Enable continuous integration: checked
Batch changes while a build is in progress: unchecked
Branch filters
Included dev branch + another feature branch
Path filters
None
I'm learning how to build the infrastructure provisioning pipelines in Azure DevOps and looking for some step-by-step tutorial to deploy for instance the vnet and a VM in Azure using both methods - ARM templates as well as Terraform
Any help highly appreciated,
Thanks,
Andrey
ARM template:
Firstly, you need have one template which it can be deployed to azure to create VM and Vnet. Just refer to this sample: azure-quickstart-templates. Then do some changes into the JSON scripts based on your actual demands.
The CI/CD structure in azure devops also very easy.
1) Build:
Since the template scripts do not need any build process, it only need 2 tasks to pack and publish the repos as artifact. So that release can use them.
- task: CopyFiles#2
displayName: 'Copy Files to: $(build.artifactstagingdirectory)'
inputs:
SourceFolder: '$(Build.SourcesDirectory)'
TargetFolder: '$(build.artifactstagingdirectory)'
- task: PublishBuildArtifacts#1
displayName: 'Publish Artifact: drop'
inputs:
PathtoPublish: '$(build.artifactstagingdirectory)'
2) Release:
In release pipeline, it just need one task: Azure Resource Group Deployment task.
This blog has detailed description on how to configure the task.
Terraform:
Same with ARM, here you also need one terraform scripts.
1) Build
For tefrraform, the build configuration same with ARM. Just need publish artifacts.
2) Relesase
See this detailed blog: Terraform deployment with Azure DevOps