We have been using CruiseControl for quite a while with NUnit and NAnt. For a recent project we decided to use the testing framework that comes with Visual Studio, which so far has been adequate.
I'm attempting to get the solution running in CruiseControl. I've finally got the build itself to work; however, I have been unable to get any tests to show up in the CruiseControl interface despite adding custom build tasks and components designed to do just that. Does anyone have a definitive link out there to instructions on getting this set up?
Not sure if that helps (i found the ccnet Documentation somewhat unhelpful at times):
Using CruiseControl.NET with MSTest
The CC.Net interface is generated via an XSL transform on your XML files put together as specified in the ccnet.config file for your projects. The XSL is already written for things like FxCop - check your server's CC xsl directory for examples - shouldn't be too hard to write your own to add in the info - just remember to add the XML output from your tests into the main log.
Related
I am trying to setup code coverage on our ASP.NET Core 2.0 web application. I use dotcover (from JetBrains) to provide code coverage on all my other builds (by running dotcover from the command-line during the build process).
When I run dotcover from our build server for our .NET Core 2.0 web app I see this.
It states that it has run successfully but then just hangs there and no code coverage files are created.
dotcover analyse /TargetExecutable:"C:\Program Files\dotnet\dotnet.exe" /TargetArguments:"test MyUnitTests.csproj" /Output:report.html /ReportType:HTML /LogFile=dotcover.log
If I try and add code coverage collection I see this.
dotcover analyse /TargetExecutable:"C:\Program Files\dotnet\dotnet.exe" /TargetArguments:"test MyUnitTests.csproj --collect:coverage" /Output:report.html /ReportType:HTML /LogFile=dotcover.log
And finally if I run dotnet test on its own (without dotcover) it seems to have worked, but again no coverage output is created.
dotnet test "MyUnitTests.csproj" -- collect:coverage
I'm unsure how to generate code coverage for a .NET Core 2.0 app, and not sure how / what data collectors are and how they should be used. Is dotcover the data collector in this example?
Basically, I just want to generate code coverage for a .NET Core 2.0 application.
UPDATE:
As per the suggestion I have installed coverlet as an alternative to dotcover. I have got it working but am getting inconsistent behaviour. When I run my batch file from the server it's all fine.
But when run from TFS I get an error.
System.IO.FileNotFoundException: No test is available in . Make sure test project has a nuget reference of package "Microsoft.NET.Test.Sdk" and framework version settings are appropriate and try again.
My project does have a reference to that assembly (it's installed by default by VS itself when you create a unit test project).
Why is TFS complaining about that assembly when it's definitely there and can be run manually from the command-line without an error?
I don't know if dotcover can works with net core, but you can take a look for coverlet, also you can find an example here: Cross platform code coverage arrives for .NET Core
I have just migrated a project from net461 to dotnet core and I wanted to maintain code coverage. Using the command line suggested by the OP was what I needed. I am migrating fake scripts where I was previously using dot cover to generate the snapshot file to be pushed to teamcity and an html report. I can confirm that the following works for me:
DotNet SDK 2.1.2
JetBrains.dotCover.CommandLineTools 2018.1.0
Also tested positive with 2017.1.20170403.131707
Microsoft.NET.Test.Sdk 15.7.0
NUnit 3.10.1
NUnit3TestAdapter 3.10.0
DotCover cover
<dotcoverpath>\dotCover.exe cover /TargetExecutable:"C:\Program Files\dotnet\dotnet.exe" /TargetArguments:"test --no-build --no-restore ./src/<test-project-root>" /Filters=+:<namespace-to-test> /Output:./bin/DotCover.snapshot
DotCover analyze
I am not doing the following as I use the DotCover report command on the generated snapshot file but I can also confirm that the following is working for me as well.
<dotcoverpath>\dotCover.exe analyze /TargetExecutable:"C:\Program Files\dotnet\dotnet.exe" /TargetArguments:"test --no-build --no-restore ./src/<test-project-root>" /Filters=+:<namespace-to-test> /ReportType=HTML /Output:./bin/coverage.html
Notes
In my test run I am not restoring packages (--no-restore) or compiling (--no-build) the project as I have already done this in a previous step. These can be removed to suit your needs.
The OP did say that dot cover appeared to hang after the tests had completed. It is worth pointing out that the effort in turning the snapshot at the end of the test coverage into a report can take a while if there is a large amount of code and or assemblies. You do in fact see dot cover pausing at the point the tests have completed whilst it generates the html report. Use the filter (/Filters=) parameter to cut down on the size of things being covered, especially if you don't want to do any coverage on third party components.
/Filters=ARG (Optional) Specifies coverage filters. Syntax:
+:module=*;class=*;function=*; Use -:myassembly to exclude an assembly from code coverage. Asterisk wildcard (*) is supported here
I'm trying to setup a CI server for a website that I'm developing, but I can't find any info regarding how to do it with the new ASP.NET 5.
I got you brother. This took me a few days to figure out. This configuration is on TeamCity v10 for a ASP.NET Core 1.0 RC2/preview2 project. As a bonus, I am including the step where it pushes to Octopus Deploy. You will need to install the dotnet teamcity plugin and the newest Octopus Deploy plugin with Push functionality. Here's an overview of the build steps:
First off, don't try to use dotnet restore to restore the packages. It won't work if you have internal nuget packages that are not compiled as .Net Core. This took forever to figure out. I would ignore trying to use dotnet restore until people have converted everything over to .Net Core or Microsoft fixes dotnet.exe to be more flexible.
Some of the stuff I read said to use the newest beta version of NuGet, 3.5. When I tried this, I would get the following error.
[14:30:09][restore] Starting NuGet.exe 3.5.0.1737 from D:\buildAgent\tools\NuGet.CommandLine.3.5.0-rc1\tools\NuGet.exe
[14:30:10][restore] Could not load type 'NuGet.CommandAttribute' from assembly 'NuGet, Version=3.5.0.1737, Culture=neutral, PublicKeyToken=31bf3856ad364e35'.
I don't know what that means, and I don't care. Use 3.4.4 for now. Fill in the rest as appropriate.
The dotnet publish step is pretty straightforward. Make sure you provide the output directory because you want to use it in the final step. Also, be sure to specify an absolute path by using the %teamcity.build.workingDir% variable because of this bug. Otherwise it will fail to find your web.config file and not finish publishing the entire site. You'll be missing things like web.config and wwwroot!
Finally we Push to Octopus. This was very tricky for me. Note the part that says
%teamcity.build.workingDir%/published-app/**/* => OrderReviewBoard.1.0.0.zip
IF ANY PART OF THIS IS INVALID, YOUR STEP WILL FAIL WITHOUT EXPLAINING ITSELF!!! By invalid, I mean maybe you put a teamcity environment variable (like the %build.number% they show in all the examples) in that zip name that doesn't properly resolve. Or you specify a non-existent path. Or any number of things, you will see an error that says "[Octopus Deploy] Please specify a package to push". That means that one was never generated because that statement failed. I realize you want to have an auto-incrementing build number there. I'll leave it up to you to figure out how to do that.
Don't get all confused by what is running here. Octopus tries to explain it on their site, but it is hidden here. There is octo pack and octo push. The new version of octo pack is running out of sight, based on whatever statement you put in that "Package paths" box. Don't get sidetracked trying to create a nuspec package, or trying to use dotnet pack. These are dead ends for our purposes. Create a .zip file and move on with your life. Finally, notice the additional command line arguments I added. These help you out a tiny bit. They aren't required. Good luck.
We (the ASP.NET team) use TeamCity as the build server. Each repo has a build.cmd file, similar to this one. TeamCity simply invokes that file.
For Mac/Linux builds, there is a build.sh file.
At the moment you can try to use TeamCity plugin for .NET Core projects:
https://github.com/JetBrains/teamcity-dotnet-plugin
Please check these blog posts;
http://blog.coderinserepeat.com/2015/01/25/building-asp-net-5-projects-in-teamcity/
http://blog.maartenballiauw.be/post/2014/12/19/Building-future-NET-projects-is-quite-pleasant.aspx
Since there has been many changes to the ASP.NET Core world and I got asked about it a few times, I wrote down a step-by-step guide on how to setup a CI/CD environment using TeamCity for .NET Core. I think it is especially helpful for beginners.
Using bamboo v5.7 with msbuild v12, how do I fail a build if there are any static code analysis warnings? We do have our projects all set to treat all warnings as errors so the project itself doesn't build, but bamboo is not detecting this and continues on.
This seems basic, what might I be doing wrong?
The simple answer is you are doing nothing wrong, nor are you missing anything.
While it seems like basic functionality, Bamboo's MSBuild task currently doesn't support reading, reporting or failing the build on Warnings or Errors. The task only fails because MSBuild (or XBuild if you are using Mono) returns with an error code when a compiler error occurs.
Also, MSBuild doesn't actually support failing on all warnings either, as you can see here.
You have a couple options.
You can use one of the options in the referenced post
You could roll your own MSBuild log parser plugin using Atlassian's Plugin SDK.
You could make a simple script that is executed after the build, reads the logs and returns a non-zero integer if there were compiler warnings.
You can vote for the issue in the Atlassian Jira and also for the related issue for parsing build details.
Whatever your solution, I hope you share it with the many of us that have run into the same problem. It seems to be something quite common, so I was surprised there wasn't an issue already open for this in Atlassian's Jira instance
For VS 2008 and later, a new project setting was added for this. See this link.
We build our solution using msbuild 4.0 from TeamCity. Our continuous build uses up quite a lot of resources, both on the build machine, and on our central signing and obfuscation servers. One thing I've noticed is that even when a project fails to compile, the build continues, and other projects that do compile get signed and obfuscated.
Is there some way to make the build halt as soon as something fails?
The MsBuild task actually supports a parameter StopOnFirstFailure. However, I can't seem to get it to have any effect.
Can I use this feature to do what I need? I'm prepared to edit e.g. the Microsoft.Common.Targets file on the build servers.
I found this answer on StackOverflow that involves emitting a proj file from the solution and then editing it. I guess I could automate that process on our build servers, but it seems a lot of work to achieve a fairly basic requirement.
Has anyone solved the problem of automatically building publisher policy assemblies as part of an automated build? I've trawled the web and there are plenty of people asking about this but no solutions.
Constructing policy assemblies is hugely error prone when done manually and in any case needs to be part of the continuous integration build that we run in TeamCity.
I'm hoping specifically for a solution that uses MSBuild and can run on TeamCity, but I can interpolate from other solutions if necessary. Surely, someone MUST have done this?