Dotnet Test not terminating in Azure Pipelines - .net-core

In our pipeline for the past 3 weeks, the dotnet test task has not been terminating at all, and we are forced to cancel the pipeline.
We have observed this log, which we had not seen prior to 3 weeks: (No changes have been made in these 3 weeks at all, either to our code or to Windows on our on premise agent, SQL Server or any other service in the agent).
The STDIO streams did not close within 10 seconds of the exit event from process 'C:\AzAgent_work_tool\dotnet\dotnet.exe'. This may indicate a child process inherited the STDIO streams and has not yet exited.
##[error]Error: The process 'C:\AzAgent_work_tool\dotnet\dotnet.exe' failed with exit code 1
All the tests in the task pass though.
Publishing test results to test run '1033120'.
TestResults To Publish 233, Test run id:1033120
Test results publishing 233, remaining: 0. Test run id: 1033120
Published Test Run :
The test results are published.
We have observed this in the logs:
*##[warning].NET 5 has some compatibility issues with older Nuget versions(<=5.7), so if you are using an older Nuget version(and not dotnet cli) to restore, then the dotnet cli commands (e.g. dotnet build) which rely on such restored packages might fail. To mitigate such error, you can either: (1) - Use dotnet cli to restore, (2) - Use Nuget version 5.8 to restore, (3) - Use global.json using an older sdk version(<=3) to build
Info: Azure Pipelines hosted agents have been updated and now contain .Net 5.x SDK/Runtime along with the older .Net Core version which are currently lts. Unless you have locked down a SDK version for your project(s), 5.x SDK might be picked up which might have breaking behavior as compared to previous versions. You can learn more about the breaking changes here: https://learn.microsoft.com/en-us/dotnet/core/tools/ and https://learn.microsoft.com/en-us/dotnet/core/compatibility/ . 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*
Hence we added this in our yaml before the test task, as our app is built with .NET Core 3.1:
- task: UseDotNet#2
inputs:
packageType: sdk
version: 3.x
installationPath: $(Agent.ToolsDirectory)/dotnet
displayName: 'Installing .net core sdk 3.x'
condition: succeeded()
I did a little investigation and found this link on the MS github page: https://github.com/microsoft/azure-pipelines-tasks/issues/13033
We have set these variables: TASKLIB_TEST_TOOLRUNNER_EXITDELAY 60000
name: 'NUGET_PLUGIN_REQUEST_TIMEOUT_IN_SECONDS'
value: 30
name: 'NUGET_PLUGIN_HANDSHAKE_TIMEOUT_IN_SECONDS'
value: 30
No effect yet. How can we solve this issue? It is not affecting our release but we would like to have a green pipeline? Tips on this would be greatly helpful

Thanks for Ashwin's answer.
There was an issue with chromedriver exe which used was not updated for chrome 89. Hence one of the tests was hanging. So then after changing the chromedriver and removing the filter, the tests ran fine and the stage terminated. So no changes to pipeline yaml were required.
Posting here so others who have the same issue can find this answer quickly.

Related

How to ensure same nuget packages versions will be used during publish and tests?

I have solution with following projects:
Api
Application
Infrastructure
Tests
Api is WebApplication (entry point) and has ProjectReferences to libraries Application and Infrastructure.
Tests is a xunit test project and has ProjectReferences to Api / Application / Infrastructure.
I want consistent package versions both during publishing main (Api) project and during running tests.
I added following properties to Api.csproj:
<RestorePackagesWithLockFile>true</RestorePackagesWithLockFile>
<RestoreLockedMode Condition="'$(CI)' == 'true'">true</RestoreLockedMode>
And it generated Api/packages.lock.json - and it seems that this file also tracks versions of dependencies of referenced projects.
Here is how I publish application (Api):
RUN dotnet restore ./Api/Api.csproj
RUN dotnet publish Api -c Release -o out --runtime alpine-x64 --self-contained true /p:PublishTrimmed=true
So if CI=true env var is set, then commands above should either restore packages according to package.lock.json or fail.
However before publishing Api I run tests like this:
dotnet test ./Tests/Tests.csproj
My question is how to ensure that exactly same package versions will be used suring testing as in Api/package.lock.json? Because if I add <RestorePackagesWithLockFile>true</RestorePackagesWithLockFile> to Tests project then it will have separate Tests/package.lock.json file which may not be same as the one in Api/package.lock.json, right? On the other hand when Tests project references Api project then from what I understand Api/package.lock.json is ignored (when running Tests project)?
Is it possible to have one package.lock.json for solution (same for all projects in solution)?
I feel a bit bad for making this an answer and possibly getting rep votes, when mu88 beat me by 12 hours in the comments to the question, but Central Package Management is the answer. There's also a blog post about it.
Currently, neither Visual Studio, nor dotnet add package support installing or upgrading packages, so you will need to hand edit all the xml (csproj, props) files. But support should be coming in VS 2022 17.4, .NET SDK 6.0.400.

Azure Pipelines Xamarin.Forms iOS build fails with error MSB4057: The target "_IsProjectRestoreSupported" does not exist in the project

We have Xamarin.Forms solution with iOS and UWP projects. We use Azure pipelines to build the iOS project. Until yesterday everything was working fine.
Now the build fails at the NuGet Restore step with the error:
##[error]The nuget command failed with exit code(1) and error(/Users/runner/work/1/s/"MyProjectName.UWP".csproj : error MSB4057: The target "_IsProjectRestoreSupported" does not exist in the project.
We can see that the problem occurs when trying to restore NuGet packages for the UWP project on the Mac OS build host.
Image: macOS-11
Workaround will be to exclude it from the solution, but we are using it for testing purposes and this is not a good option for us.
We had the same problem yesterday for our iOS (macos-11) and Android (macos-10.15) Pipelines.
The issue 21180 for mono seems to be the root cause, which is also referenced in a pull request to update the mono version for MacOs virtual environments. Regarding to this workflow test we gave msbuild a chance, and it works.
Solution:
Instead of NuGet restore we use directly MSBuild.
- task: MSBuild#1
inputs:
solution: 'App.sln'
configuration: 'Release'
msbuildArguments: /t:restore
Looking at the log file, MSBuild ignores the UWP project. That is the behavior that NuGet had with the older mono version 6.12.0.125. Ignoring the UWP-Project is no problem, because it can only be build on windows environments.
Project "/Users/runner/work/1/s/App.sln" on node 1 (Restore target(s)).
ValidateSolutionConfiguration:
Building solution configuration "Release|Any CPU".
/Library/Frameworks/Mono.framework/Versions/6.12.0/lib/mono/msbuild/Current/bin/NuGet.targets(315,5): warning : Skipping restore for project '/Users/runner/work/1/s/App/App.UWP/App.UWP.csproj'. The project file may be invalid or missing targets required for restore. [/Users/runner/work/1/s/App.sln]
Some additional information:
The NuGet restore task uses msbuild to find all referenced packages. If that fails, it will use the packages.config file as fallback, the pipeline step will not fail.
Instead we got an error in the build steps for Android & iOS:
error NETSDK1004: Assets file
'/Users/runner/work/1/s/../obj/project.assets.json' not found. Run a
NuGet package restore to generate this file.
Updated Answer
This can be resolved using MSBuild task instead, as the collogues mentioned below.
However, in my case this still lead to the same error. After investigating the pipeline. The root cause has been identified:
Both in MSBuild#1 and XamariniOS#2 tasks
you should target the specific iOS Project and not the solution file, like so:
"
- task: MSBuild#1
inputs:
solution: 'PathToIosProject/myproject.iOS.csproj'
configuration: '$(BuildConfiguration)'
msbuildArguments: /t:restore
" - task: XamariniOS#2
inputs:
solutionFile: PathToIosProject/myproject.iOS.csproj'
configuration: '$(BuildConfiguration)'
packageApp: true
signingIdentity: $(APPLE_CERTIFICATE_SIGNING_IDENTITY)
Old Answer
We have managed to resolve the issue. The root cause of it seems to be an update to the mono framework in the MacOS pipeline build agent.
In order to fix it, we need a script for downloading and installing an older version of the mono framework as a first step of the build pipeline like so:
link to the pipeline tasks photo
This is the code of the bash scrip used in the task:
#!/bin/bash
set -ex
MONO_MACOS_PKG_DOWNLOAD_URL='https://download.mono-project.com/archive/6.12.0/macos-10-universal/MonoFramework-MDK-6.12.0.100.macos10.xamarin.universal.pkg'
mkdir -p /tmp/mono-install
cd /tmp/mono-install
mono --version
wget -q -O ./mono-installer.pkg "$MONO_MACOS_PKG_DOWNLOAD_URL"
sudo installer -pkg ./mono-installer.pkg -target /
mono --version
ls -alh /Library/Frameworks/Mono.framework/Versions/Current

How do you use multiple dotnet core unit test target frameworks in Travis-CI?

I am developing an api targeting .NetStandard, and want to test it with different versions of .NetCore.
I would like to run my unit tests against all the currently supported LTS versions of .NetCore, however I cannot figure out how to build the unit tests against the currently installed SDK.
The currently supported versions of .NetCore are 2.1 and 3.1. I can use <TargetFrameworks> to specify that the unit test project can handle both those targets, and when I run on my dev machine everything works fine. However, unlike my dev machine, when Travis runs tests there is only one SDK installed (which is good - I want to know exactly what I'm testing against). The unit test project expects both SDKs to present, however. If I target only 2.1 it fails for 3.1 on Travis, and if I target 3.1 it fails for 2.1.
So, is there a way to test against both LTS versions of .NetCore on Travis-CI with a single unit test project?
Was able to get it working.
In the unit test project use TargetFrameworks instead of TargetFramework to target multiple frameworks. I believe you have to edit the csproj file by hand, I don't think there's a way to set it from the Visual Studio UI. <TargetFrameworks>netcoreapp2.1;netcoreapp3.1</TargetFrameworks>
In .travis.yml, include one framework in the dotnet: section, explicitly install the other framework in the before_install: section, then explicitly invoke the tests with each framework in the script: section:
dotnet: # Include one of the frameworks
- 2.1.804 # EOL for 2.1: 2021.08.21
before_install:
# explicitly install other targeted SDKs side by side
- sudo apt-get install dotnet-sdk-3.1
script:
# explicitly identify the framework when invoking the tests
- dotnet test UnitTests/UnitTests.csproj -f netcoreapp2.1
- dotnet test UnitTests/UnitTests.csproj -f netcoreapp3.1

Cannot push dotnet 3.0.100 app to Octopus from Azure DevOps

I’m using the DevOps pipeline to push my dotnet build to an Octopus cloud instance.
It worked fine until I added the dotnet SDK 3 installer to the devops pipeline
- task: UseDotNet#2
displayName: 'Install .net core 3.0.100'
inputs:
packageType: sdk
version: '3.0.100'
installationPath: $(Agent.ToolsDirectory)/dotnet
The octopus part of my azure-pipelines.yml looks like this:
- task: OctoInstaller#4
inputs:
version: 'latest'
- task: OctopusPush#4
inputs:
OctoConnectedServiceName: 'XXX.octopus.app'
Space: 'Spaces-1'
Package: '$(Build.ArtifactStagingDirectory)/$(Build.DefinitionName).$(Build.BuildNumber).zip'
Replace: 'false'
I have tried every combination of OctoInstaller that I can think of including embedded and explicit version numbers. I keep getting this error message with #4.
Failed to push package. The Octo command line tool is too old to run this task. Please use version 6.10.0 or newer, or downgrade the task to version 3.*.
With OctoInstall#3 I get another error:
Failed to push package. The process '/opt/hostedtoolcache/dotnet/dotnet' failed with exit code 150
Has anyone been able to use dotnet 3 with Octopus deploy? One option
might be to install the octo extension for dotnet but I’m not sure how
you would do that from the azure pipeline. Or to use a Windows build
instead of Ubuntu.
I also noticed an error in the build step.
The specified framework 'Microsoft.NETCore.App', version '2.0.0' was not found.
- The following frameworks were found:
3.0.0 at [/opt/hostedtoolcache/dotnet/shared/Microsoft.NETCore.App]
This means that octopus must be trying to use the dotnet 2 framework.
After looking carefully at the logs, I discovered that OctopusPush was failing because it depends on dotnet 2.0.0. I added in a yml task to install that framework and now it pushes to octopus.
It might be neater to use the dotnet octo tool, as described by TrevorBrooks however I don't know how to install dotnet extensions in the DevOps Pipeline.
Use dotnet octo https://octopus.com/blog/octopus-and-netcore
The blog article explains in detail how to make this work.
For Azure Pipelines follow this article: https://octopus.com/docs/packaging-applications/build-servers/tfs-azure-devops/using-octopus-extension
Keep in mind
The Azure DevOps extension tasks require Octo to be available on the
path when executing on a build agent and must have the .net core 2.0.0
runtime or newer installed. This may not always be possible such as
with the Azure DevOps hosted agents. In order to make this work, all
Octopus tasks will automatically attempt to download and use the
latest version of Octo tools unless they're available on the build
agent as specified above. If you would like to avoid any additional
downloads or to use a specific Octo version then you can by adding the
Octo Installer task to the start of your build definition. No attempt
will be made to download Octo if the capability is detected on your
build agent.

Not getting code coverage in SonarCloud from an Azure Devops .NET core build

I have set up a pipeline for my .NET Core project in Azure Devops using the '.NET Core with SonarCloud' template. When I build the analysis gets run in SonarCloud but with 0% Code coverage (I have tests in my solution).
No matter what configuration tweaks I make to the build I cannot get the code coverage working.
What am I missing?
I came across this article and https://dejanstojanovic.net/aspnet/2019/may/publishing-code-analysis-to-sonarcloud-from-azure-build-pipeline/ implemented the powershell script described in it but still I get no code coverage in SonarCloud
I tried using coverlet as described here but still no joy
https://gunnarpeipman.com/aspnet/azure-devops-code-coverage/
My pipeline consists of the following tasks
.NET Core - Restore
Prepare Analysis Configuration
.NET Core - Build
.NET Core - Test
Run Code Analysis
Publish Quality Gate Result
My test task is configured:
Arguments: --configuration $(BuildConfiguration)
Publish test results and code coverage - checked
In the console of the Run Code Analysis task I get:
10:43:54.7 Fetching code coverage report information from TFS...
10:43:54.702 Attempting to locate a test results (.trx) file...
10:43:54.753 Looking for TRX files in: C:\\TFSBuilds\\TJPYHG04-GHJ01\\_work\\475\\TestResults
10:43:54.755 No test results files found
10:43:54.81 Did not find any binary coverage files in the expected location.
10:43:54.811 Falling back on locating coverage files in the agent temp directory.
10:43:54.812 Searching for coverage files in C:\\TFSBuilds\\TJPYHG04-GHJ01\\_work\\_temp
10:43:54.814 No coverage files found in the agent temp directory.
hope this answer still relevant to you.
Recently I have similar problem as you and I am also using Azure DevOps for my case.
This is how I solved it.
Step 1 - Change directory into your unit testing sub folder (same as the unit-testing .csproj file) and run the following dotnet command.
dotnet add package coverlet.msbuild
Step 2 - Add followings into SonarCloudPrepare Task Additional Properties or append directly into the yml file (if you're using yml instead of classic editor)
extraProperties: |
sonar.exclusions=**/obj/**,**/*.dll
sonar.cs.opencover.reportsPaths=$(Build.SourcesDirectory)/**/coverage.opencover.xml
sonar.cs.vstest.reportsPaths=$(Agent.TempDirectory)/*.trx
The directory is up to your choice to configure.
Or you can also create a file at your repo titled sonar-project.propertiesand store all the relevant SonarCloud properties inside.
Step 3 - Add followings into your dotnet test task
- task: DotNetCoreCLI#2
inputs:
command: 'test'
arguments: '--configuration $(BuildConfiguration) /p:CollectCoverage=true /p:CoverletOutputFormat=opencover --logger trx'
testRunTitle: 'dotnet test'
You may notice there's a tickbox for "Publish test results and code coverage" but I still prefer using /p:CollectCoverage=true.
You may also test locally to run the dotnet test /p:CollectCoverage=true /p:CoverletOutputFormat=opencover --logger trx command and coverage.opencover.xml will be generated at your unit testing folder.
Refer to reference 2 & 3 for more parameters and their description.
Side Note: If you're doing any Sonar test inclusion properties, note that Sonar.Tests and Sonar.Test.Inclusions their Test(s) are different. lol
References:
Using SonarCloud in Azure pipelines
Analysis Parameters (official docs)
Test Coverage & Execution (official docs)
Hope this helps :)
Not getting code coverage in SonarCloud from an Azure Devops .NET core build
This issue may caused by vstest output path changed recently:
The output path of the vstest coverage file change from
D:\a\1\s\TestResults\... to D:\a\_temp\...
Which broke subsequent scripts in the pipeline (like, codecoverage.exe to convert to xml and later import to sonarqube).
Microsoft suggest that use the rest APIs to check for the test artefacts and re-download them to the build agent.
More investigation on this issue, you can check the thread Azure DevOps (VSTS) extension no longer import coverage and unit tests automatically for the issue tracking.
Fortunately, SonarSourcer team have just release new versions of the SonarQube (v4.6.3) and SonarCloud (v1.6.3) extensions to address the coverage issue and the regression.
Hope this helps.

Resources