The error I am getting :
The test source file "D:\a\_work\3\s\MyProject.UnitTests\bin\Release\net6.0\MyProject.UnitTests.dll" provided was not found.
##[error]Error: The process 'C:\hostedtoolcache\windows\dotnet\dotnet.exe' failed with exit code 1
##[warning]No test result files were found.
##[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
Related yml script:
steps:
- task: DotNetCoreCLI#2
displayName: "Run unit tests"
inputs:
command: test
projects: "**/*MyProject.UnitTests/*.csproj"
arguments: --configuration $(projectBuildConfiguration) --no-build --no-restore
feedsToUse: 'config'
nugetConfigPath: 'nuget.config'
The tests are running all fine in my local machine.
Project build configuration is release
Since you don't have a separate build step you should not be passing the --no-build --no-restore flags.
Related
If there is more information needed, let me know in the comments.
Automated testing is supposedly supported fairly readily in Azure DevOps, by way of adding one or more tasks to your pipeline, which can be triggered after pushing new commits and having your software built automatically. With Visual Studio, this would generally take the form of DevOps building your Visual Studio solution, then running one or more test projects that are, more than likely, a part of that solution.
My problem is this: There does not seem to be one, single example of how to actually do this. And when I try, I get this error:
This task is supported only on Windows agents and cannot be used on other platforms.
This is after adding the Visual Studio Test task. When using a minimal pipeline, the solution is able to build fine, and the pipeline runs correctly. When adding a very, very basic task to run the unit tests, the error message above is returned.
I have tried searching around for clear instructions or examples of how to set this up, and I have tried searching for that particular error. What results do come up are simply not very informative.
Because clear instructions don't exist elsewhere, I will ask on SO: What are the basic, but clear steps needed to set up an Azure DevOps pipeline which will build a Visual Studio solution which uses .NET Core, then run the test project(s) inside?
Visual Studio Test task is required to be run on Windows. Take a look at the example - in pool:vmImage: ubuntuLatest I am specifying to get a concrete machine to run all my steps inside. See the list of default machines hosted by Microsoft. For instance, you can use windows-latest to have your Visual Studio Test step run properly.
However, Azure DevOps introduced a new set of dotnet core CLI tasks to build and test .net core applications (Windows is not required to perform them).
I found really nice description from Scott Hanselman's blog. It would build, test, and publish your solution with .net core projects.
trigger:
- main
pool:
vmImage: 'ubuntu-latest'
variables:
buildConfiguration: 'Release'
steps:
- task: UseDotNet#2
displayName: ".NET Core 3.1.x"
inputs:
version: '3.1.x'
packageType: sdk
- script: dotnet build --configuration $(buildConfiguration)
displayName: 'dotnet build $(buildConfiguration)'
- task: DotNetCoreCLI#2
displayName: "Test"
inputs:
command: test
projects: '**/*tests/*.csproj'
arguments: '--configuration $(buildConfiguration)'
- task: DotNetCoreCLI#2
displayName: "Publish"
inputs:
command: 'publish'
publishWebProjects: true
arguments: '-r linux-x64 --configuration $(BuildConfiguration) --output $(Build.ArtifactStagingDirectory)'
zipAfterPublish: true
- task: PublishBuildArtifacts#1
displayName: "Upload Artifacts"
inputs:
pathtoPublish: '$(Build.ArtifactStagingDirectory)'
artifactName: 'hanselminutes'
Later you can play with official MSDN documentation to add code coverage, test results, etc.
I have recently encountered an issue with building my ember project with bitbucket pipelines:
+ ember build --environment="production"
Could not start watchman
Visit https://ember-cli.com/user-guide/#watchman for more info.
Building
Environment: production
cleaning up
cleaning up...
Build Error (broccoli-persistent-filter:Babel > [Babel: ember-data]) in ember-data/adapters/json-api.js
Cannot use the decorators and decorators-legacy plugin together
I am currently using ember-cli version 3.8.1.
The issue occurs with all build environments, not just production.
What baffles me is that no new npm package or ember addon was added between last successful build and the ones that have been failing since - and now if I re-run the successful build, that will also fail.
I have gone back in the commit history to a commit that worked, then fast-forward into the present step-by-step - always deleting the node_modules and reinstalling the packages. It always works locally, but it will always fail when the pipeline is run.
I have also tried updating my docker image.
I have already gone through and tried the solutions listed here - but it seems like they have already been addressed in version 3.8.1.
Also, if it is any help, this is my bitbucket-pipelines.yml:
pipelines:
branches:
master:
- step:
name: Building Ember Project
script:
- npm install
- npm install firebase-tools
- ember build --environment="production"
- step:
trigger: manual
deployment: production
name: Deploy to Production
script:
- firebase use prod
- firebase deploy --non-interactive --token ${FIREBASE_TOKEN}
Thank you all in advance!
This sounds like a sub-dependency changing on the fly under the hood. Do you have an npm or yarn lockfile commited as part of your repo? Lockfiles are specifically designed to keep from hitting snags like this
I have gone through the below errors,
Build error : “Cannot use the decorators and decorators-legacy plugin together”
Build error: 'relationshipStateFor' is not exported by -private\system\record-data-for.js
On browser got Expected store.createRecordDataFor to be implemented but it wasn't.
Reason for the above error is with ember-data addon and mismatch in ember-cli version installed for my project.
In your package.json, You might have defined ember-cli version( "ember-cli": "^3.11.0",) with ^ symbol this means it will install latest version which is less than the 4.0.0. So your ember-cli in node_modules might be installed to the latest version.
The above mentioned error is caused by the ember-cli version which was installed and pointed to 3.15.0. So I have removed the ^ and updated "ember-cli": "3.11.0", and removed node_modules and did npm install that solves the above problem.
I'm trying to use Azure DevOps Pipelines to build my .NET Core 2.1 solution from GitHub. It includes a SQL project that has a TargetFrameworkVersion of v4.6.2. This project always fails to build.
Build FAILED.
/home/vsts/work/1/s/MySolution/MyDatabase/MyDatabase.sqlproj : warning NU1503: Skipping restore for project '/home/vsts/work/1/s/MySolution/MyDatabase/MyDatabase.sqlproj'. The project file may be invalid or missing targets required for restore. [/home/vsts/work/1/s/MySolution/MySolution.sln]
/home/vsts/work/1/s/MySolution/MyDatabase/MyDatabase.sqlproj(57,3): error MSB4019: The imported project "/usr/share/dotnet/sdk/2.1.403/Microsoft/VisualStudio/v15.0/SSDT/Microsoft.Data.Tools.Schema.SqlTasks.targets" was not found. Confirm that the path in the <Import> declaration is correct, and that the file exists on disk.
1 Warning(s)
1 Error(s)
How do I reference or include those targets for the build server? It builds fine in VS2017. I've spent more than a day hunting and cannot find any information on this problem.
Thanks to Herman Cordes for directing my investigation.
The problem was the selected build server. SSDT is a Windows-only package, so I had to use a Windows VM instead of the default Ubuntu VM, and use the VSBuild#1 task instead of DotNetCoreCLI#2.
azure-pipelines.yml
pool:
vmImage: 'vs2017-win2016'
steps:
- task: VSBuild#1
displayName: 'vsbuild $(buildConfiguration)'
inputs:
configuration: $(buildConfiguration)
EDIT: The MSBuild#1 task also works.
Here is a solution for linux build agent
Easiest way to build DacPac file on a linux agent is done via MSBuild.Sdk.SqlProj
Go to your database project directory in parallel to .sqlproj file create a directory like DB.Build under it create DB.Build.csproj copy.pase the content as below
<Project Sdk="MSBuild.Sdk.SqlProj/1.1.0"> <!-- This will pull in the required tools and dependencies to build a .dacpac with .NET Core -->
<PropertyGroup>
<TargetFramework>netstandard2.0</TargetFramework>
</PropertyGroup>
<ItemGroup>
<Content Include="..\src\DB\masterdata\**\*.sql" /> <!-- link in the new .csproj to the .sql scripts in your existing database project -->
</ItemGroup>
</Project>
After run you will see dacpac file appears under DB.Build/bin/Release/netstandard2.0/DB.Build.dacpac
Here's my build agent output (Ubuntu agent on Azure devops)
Starting: SQL DB build Release
==============================================================================
Task : .NET Core
Description : Build, test, package, or publish a dotnet application, or run a custom dotnet command
Version : 2.187.0
Author : Microsoft Corporation
Help : https://learn.microsoft.com/azure/devops/pipelines/tasks/build/dotnet-core-cli
==============================================================================
Info: .NET Core SDK/runtime 2.2 and 3.0 are now End of Life(EOL) and have been removed from all hosted agents. If you're using these SDK/runtimes on hosted agents, kindly upgrade to newer versions which are not EOL, or else use UseDotNet task to install the required version.
/opt/hostedtoolcache/dotnet/dotnet build /home/vsts/work/1/s/src/RecommenderAPI.DB/RecommenderAPI.DB/RecommenderAPI.DB.Build/RecommenderAPI.DB.Build.csproj -dl:CentralLogger,"/home/vsts/work/_tasks/DotNetCoreCLI_5541a522-603c-47ad-91fc-a4b1d163081b/2.187.0/dotnet-build-helpers/Microsoft.TeamFoundation.DistributedTask.MSBuild.Logger.dll"*ForwardingLogger,"/home/vsts/work/_tasks/DotNetCoreCLI_5541a522-603c-47ad-91fc-a4b1d163081b/2.187.0/dotnet-build-helpers/Microsoft.TeamFoundation.DistributedTask.MSBuild.Logger.dll" --configuration Release /p:DeployOnBuild=true /p:WebPublishMethod=Package /p:PackageAsSingleFile=true /p:SkipInvalidConfigurations=true /p:PackageLocation=/home/vsts/work/1/recommender-service-cicd/DacPac/
Microsoft (R) Build Engine version 16.5.0+d4cbfca49 for .NET Core
Copyright (C) Microsoft Corporation. All rights reserved.
Restore completed in 51.72 ms for /home/vsts/work/1/s/src/RecommenderAPI.DB/RecommenderAPI.DB/RecommenderAPI.DB.Build/RecommenderAPI.DB.Build.csproj.
Using package name RecommenderAPI.DB.Build and version 1.0.0
Using SQL Server version Sql150
Deleting existing file /home/vsts/work/1/s/src/RecommenderAPI.DB/RecommenderAPI.DB/RecommenderAPI.DB.Build/obj/Release/netstandard2.0/RecommenderAPI.DB.Build.dacpac
Writing model to /home/vsts/work/1/s/src/RecommenderAPI.DB/RecommenderAPI.DB/RecommenderAPI.DB.Build/obj/Release/netstandard2.0/RecommenderAPI.DB.Build.dacpac
RecommenderAPI.DB.Build -> /home/vsts/work/1/s/src/RecommenderAPI.DB/RecommenderAPI.DB/RecommenderAPI.DB.Build/bin/Release/netstandard2.0/RecommenderAPI.DB.Build.dacpac
Build succeeded.
0 Warning(s)
0 Error(s)
Time Elapsed 00:00:01.71
Finishing: SQL DB build Release
Note: Make sure to restore you NuGet packages in step prior to build
Your ADO pipeline manifest should look like this:
...
- task: DotNetCoreCLI#2
displayName: 'Restore SQL Project'
inputs:
command: 'restore'
projects: '**/*DB*/*.csproj'
feedsToUse: 'select'
vstsFeed: 'db-feed'
...
- task: DotNetCoreCLI#2
displayName: 'SQL DB build $(buildConfiguration)'
inputs:
command: build
projects: '**/*DB*/*.csproj'
platform: '$(buildPlatform)'
arguments: '--configuration $(buildConfiguration) /p:DeployOnBuild=true /p:WebPublishMethod=Package /p:PackageAsSingleFile=true /p:SkipInvalidConfigurations=true /p:PackageLocation=$(Pipeline.Workspace)/$(pipelineArtifactName)/DacPac/'
I was having the exact same issue building a SQL Server project on an Azure DevOps CI/CD pipeline. None of the pre-built build tasks would work for me!
I solved this by avoiding to add a SQL Server project to the solution.
I achieved this by using an MSBuild SDK, capable of producing a SQL Server Data-Tier Application package (.dacpac) from the set of SQL scripts. By adding this second project to the solution, I managed to continue taking advantage of linking the project to a live database through SQL Server Object Explorer on Visual Studio. I gave a more detailed explanation about my implementation in this answer.
I managed to setup Yarn in Angular app and when I run: yarn install
it successfully installs all the packages which makes the app run with no issues.
Inside package.json I have written some scripts to help me out run the specific task (I want node_modules folder to be inside wwwroot).
"scripts": {
"install-dev": "yarn install --modules-folder ./wwwroot/node_modules",
"install-ci": "install --modules-folder ./wwwroot/node_modules",
}
When I have to install packages locally I use yarn run install-dev, which works perfectly.
However, when I need to build the project using Visual Studio Team Services, using Yarn Build and Release Tasks by Geek Learning I pass in run install-ci inside VS Team Services Arguments which fails with the following error:
VS Console.png
What I find weird is that it says Version: 1.1.1001, but under it writes yarn run v0.27.5. It seems like that version v0.27.5 does not support --modules-folder (and anyway why is it running the wrong version?).
Here is how Yarn task is configured in Visual Studio Team Services - VS Yarn task configuration.png.
I am making sure that I am in the correct branch (bower-to-yarn) as well as pointing to the Project Directory - src/MyApp where I have package.json file. Also, it says that the task should run with Version: 1.*.
Any help would be very useful. Thank you!
The reason why I have "install-ci" without yarn is because inside vsts console yarn gets loaded and does not need to be specified again. The same applies to Arguments field inside Visual Studio Team Services run install-ci.
I'm trying to run unit tests against our AngularCLI project using our hosted VSTS build agents however it keeps running into trouble when it tries to run 'ng test'.
To resolve this I have tried to make the agent use the ng tool directly by providing the path to the tool. This hasn't worked as it looks like it's trying to run 'ng test' where the tool is rather than in the specified current working directory:
I've also tried to add it as an environment variable in Windows (we're using Windows Server 2012 to host the VSTS agent) and setting the tool in the VSTS agent as just ng however it doesn't appear to be finding the ng tool:
How can I get the VSTS agent to make use of the ng tool to run tests? We have got #angular/cli installed on the server hosting the agent.
The thing is that you won't get angular cli installed on VSTS globally as its build server is not supporting that. But the good thing you not even need cli globally installed on your agent.
All you need is npm run ng build -- prod - this way it will always run the local version. Also this way you won't need to take care of updating your global package at all.
Use npm run ng test to run tests, npm run ng e2e to run protractor. If you need to pass any more params to any of these just use --
As mentioned by #Kuncevic, to use the Angular CLI without installing it globally, you will need to use the npm run command.
To run an Angular build using Azure Devops:
Add an npm task to install dependencies (choose install for the command)
Add another npm task, but choose custom for the command. Then add your command and arguments:
run ng -- build --output-path=dist --configuration=prod
Note how npm is not a part of the command and arguments since this will be provided by the task. Also note how -- separates the command to be run and the arguments to be passed to the command.