I have configured dotCover on my build on TeamCity. But sometimes it just stops working. There is no error. Just I don't have any new entries in the log. It ends with a timeout (timeout is configured for the whole build, not some dotcover timeout).
Part of the log of one of a failed build
! 14:55:14 Starting test execution, please wait...
14:55:14 Starting test execution, please wait...
14:55:14 Starting test execution, please wait...
14:55:14 A total of 1 test files matched the specified pattern.
14:55:14 Starting test execution, please wait...
14:55:14 A total of 1 test files matched the specified pattern.
14:55:14 Starting test execution, please wait...
14:55:14 A total of 1 test files matched the specified pattern.
14:55:15 A total of 1 test files matched the specified pattern.
14:55:15 A total of 1 test files matched the specified pattern.
15:01:37 The build MyApp::Build and Test #1.6.3-rc.3224 {buildId=634051} has been running for more than 8 minutes. Terminating...
15:01:37 Execution timeout
Previously it happens also in the middle of running tests. Today, after the dotcover update I tried to verify this problem. In 30 builds it happens once. But sometimes it is more frequent (I don't have enough old data to verify it).
I updated dotCover to 2022.2.4 Cross-Platform (the newest Cross-Platform version available on TeamCity). I'm using TeamCity 2021.2.1 (build 99602) (I'm a little scared about updating it).
I have the newest version of xUnit (2.4.2)
As a temporary solution, I configured a retry build on any error (I'm wondering if there is a possibility to retry only on timeout).
Related
I am using TeamCity build server for my CI process. I have a scenario, where i need to compare my previous and current build log and check for warnings in the code ad if the warnings count in the current is greater than the previous build, we have to fail the build.
I have two build steps namely:
For MS build
A powershell script to compare the builds ( previous build and current build)
I understand we can get the build information using the TeamCity API which is http:// /httpAuth/downloadBuildLog.html?BuildId=<< current build id >>
Is there anyway to get the build log while the build is in running state, and pass on to my second step ?
I have several build steps that need to run regardless of (test failure, in this case).
However when tests in one step fail, the whole build fails and quits. To overcome this problem I unchecked the "build process exit code is not zero".
After this the build fails more quickly at step 2, which is install of grunt-cli
Is there a (better) way to have my build continue, even on a non-zero exit from a previous step? I tried muting, but this is not what I was hoping for.
TeamCity Enterprise 9.1.7 (build 37573)
If this is a commandline build step, you can add "exit 0" to force the exit code to always be 0. Since you are reporting tests, you will still see the failed tests in TeamCity.
When you configure the build stteps, you can set an execution condition of Execution policy to: Even if some of previous steps failed
You can also set to: Always, even if build stop command was issued if you want to do some cleanup on your agent after the execution of your tests.
I’m integrating SonarQube in our build system – I installed sonar-runner-2.4 on our build agents and added the sonar-runner.properties for each solution (to the solution’s folder on TFS).
When running the build I’m executing the sonar-runner after the solution has been compiled on the build agent.
Everything seem to work except for the unit test:
On the build’s log I see that almost 200 tests ran and were completed successfully and in the sonar-runner log I see the following:
14:23:29.808 INFO - 583/583 source files analyzed
14:23:30.809 INFO - Sensor org.sonar.plugins.csharp.squid.CSharpSquidSensor#1a50b87 done: 14937 ms
14:23:30.809 INFO - Sensor org.sonar.plugins.csharp.core.CSharpUnitTestResultsProvider$CSharpUnitTestResultsImportSensor#97edbc...
14:23:30.821 INFO - Sensor org.sonar.plugins.csharp.core.CSharpUnitTestResultsProvider$CSharpUnitTestResultsImportSensor#97edbc done: 12 ms
Which seems ok I guess, but when logging into the sonar server it shows that 0 tests ran.
On the sonar-runner.properties file I set the following value to
sonar.cs.vstest.reportsPaths:
sonar.cs.vstest.reportsPaths=TestResults/*.trx
when in this case there are 3 vstest trx files located in the following local path on the build agent: `
D:\sTFS\22965\Sources\TestResults
` (see TestResults.jpg attached).
Attached is the sonar-runner.properties file.
I also attached a screen capture from the sonarqube server (see SonarServer.jpg attached).
Can you please advise what might be the problem?
You should be seeing some messages like:
INFO - Parsing the Visual Studio Test Results file ...
for each unit test result file that is being parsed, see VisualStudioTestResultsFileParser.java#L34
Can you try to pass an absolute path pattern to sonar.cs.vstest.reportsPaths? My guess is that the issue comes from the relative path.
By the way, the use of the sonar-runner to analyze .NET projects is being deprecated. You'll want to have a look at the MSBuild SonarQube Runner that offers very good integration with Team Foundation Server. See the new C# plugin documentation on SonarSource's Wiki: http://docs.sonarqube.org/display/PLUG/C%23+Plugin
EDIT
I just noticed the package name from your logs org.sonar.plugins.csharp.core.CSharpUnitTestResultsProvider. The .core. was present only in outdated versions of the C# plugin (in the 3.x series), and these versions might not support wildcards in report paths. Please upgrade to the latest version.
I have a Hudson server that runs maven 3 jobs to compile Java code. In one instance, a particular job's build log indicates that the compilation and unit tests all ran successfully, and the build completed in a successful state and another chained job was called, all indicated that Hudson believed the job to be successful. The log shows:
20:44:11 [INFO] BUILD SUCCESS
20:44:11 [INFO] ------------------------------------------------------------------------
20:44:11 [INFO] Total time: 1:35:43.774s
20:44:11 [INFO] Finished at: Mon Mar 24 20:44:11 CDT 2014
20:44:40 [INFO] Final Memory: 51M/495M
20:44:40 [INFO] ------------------------------------------------------------------------
20:44:42 channel stopped
20:44:42 [locks-and-latches] Releasing all the locks
20:44:42 [locks-and-latches] All the locks released
20:44:43 Archiving artifacts
20:45:33 Updating JIRA-1234
20:45:33 Description set: 1.23.567
20:45:33 Labelling Build in Perforce using ${BUILD_TAG}
20:45:33 [jobname] $ /usr/local/bin/p4 -s label -i
20:45:33 Label 'hudson-jobname-45' successfully generated.
20:45:33 [DEBUG] Skipping watched dependency update; build not configured with trigger: jobname #45
20:45:33 Finished: SUCCESS
However, the Hudson job page shows a "red ball" and that job run is listed as "Last failed build (#45)" on the job page. When I look at the hudson#hudson:~hudson/jobs/jobname/builds/45/build.xml file, there is a line that says
<result>FAILURE</result>
Assuming this was where the final result was captured, I changed this to
<result>SUCCESS</result>
and reloaded the page, but the red ball is still showing on the job page for that instance. I have not restarted the server to attempt to re-read the info from disk.
To be fair, there were some environmental issues around this build. Some hours later, I got a message that more than one Hudson server instance was running against the same disk image and confirmed this with
ps -ef | grep hudson.war
on the server console, showing two running processes. The job page says this run "Took 0 ms", even though the log says "Total time: 1:35:43.774s". This is Hudson ver. 2.2.1 running on "CentOS release 5.4 (Final)".
My questions:
What are the criteria for each of the job statuses? (Stable, Failed, Unstable, Aborted and Disabled statuses)?
When and where is that data captured in the running server, and can it be modified?
You have too many questions in one post.
As for "What are the criteria for each of the job statuses? (Stable, Failed, Unstable, Aborted and Disabled statuses)?"
Disabled is when a project/job is disabled from configuration (done by user with permissions). This is not a run status.
The rest are Job Run statuses:
Aborted is when a run has been cancelled/aborted. This happens when a user (with permissions) clicks the red cross button to cancel a running build. I believe SCM checkout failure also causes aborted status (but not too sure about that)
Unstable is a special status that can be applied to the job run. Usually this is done by job configuration (such as Maven) or through plugins such as Text-finder plugin. I am not aware of a way to induce unstable status through command line. Maybe through a groovy script, like plugins do. Most of the times, unstable is set by the job configuration itself, indicating failed test.
Stable and Failed are the direct result of Build Step's exit code. If the build step, such as Execute Shell, exits with exit code 0, the build step is considered success. Anything other than 0 is considered failed. If during execution of a build step, the process exits with anything other than 0, it is considered failed. If there are multiple build steps (Free-style project jobs), the last Build Step's exit code marks the status of the whole run. Once again, any Build Step in between that exits with anything other than 0 will mark the build failed.
Post-build actions, such as Text-finder plugin can also change the status of the job run.
You are not supposed to be tinkering with job history files to change the status of previous jobs. If you need to change the job result, use post-build actions such as Text-finder plugin, but even then, it only allows to downgrade the result.
Here's a one liner to printing the commit SHA1 in a jenkins job using groovy post-build script:
println "git rev-parse HEAD".execute().text
You can save this to a variable or export it as a build parameter.
I'm working with sonar having Gallio using OpenCover, it gives me a code coverage of 0% although there are test classes and my machine takes about 15 seconds to try to run the tests (at least it seems like that), after which they're summed up with the line 0 run, 0 passed, 0 failed, 0 inconclusive, 0 skipped.
So, I took a look around the internet / stackoverflow and found out that this could have to do with the code being compiled on another machine. As that's the case here as well, I opened the solution in Visual Studio, built it and I can see that my PDB files are recreated. After which I tried sonar with opencover again.
It didn't help
I took the line of code with which OpenCover is called out of the admin console, went to the OpenCover directory and executed the same line, without a filter as my coverage-report.xml told me that the test modules were skippedDueTo="Filter". After which they were not skipped anymore.
Still, 0% test coverage
I registered OpenCover profiler library with regsvr32 OpenCover.Profiler.dll in the same Admin console (and tried it twice, as I'm on windows 7 but am using a 32 bit sonar).
Didn't help
I tried the same line with adding the -oldStyle argument
Didn't help either
Now I feel like I'm out of options ...
The latest call I tried in the admin console:
C:\Program Files\OpenCover>OpenCover.Console.exe -register:user -target:"C:\Program Files\Gallio\bin\Gallio.Echo.exe" -targetdir:D:\projecten\udbdrm\source\CDP\CDPBackoffice\Develop\CDPBackoffice.root\CDPBackoffice\.sonar "-targetargs:\"/r:IsolatedAppDomain\" \"/report-directory:D:\projecten\udbdrm\source\CDP\CDPBackoffice\Develop\CDPBackoffice.root\CDPBackoffice\.sonar\" \"/report-name-format:gallio-report\" \"/report-type:Xml\" \"D:\projecten\udbdrm\source\CDP\CDPBackoffice\Develop\CDPBackoffice.root\CDPBackoffice\CDPBackoffice.BusinessLogic.Tests\bin\Debug\CDPBackoffice.BusinessLogic.Tests.dll\" \"D:\projecten\udbdrm\source\CDP\CDPBackoffice\Develop\CDPBackoffice.root\CDPBackoffice\CDPBackoffice.Utility.Tests\bin\Debug\CDPBackoffice.Utility.Tests.dll\" \"D:\projecten\udbdrm\source\CDP\CDPBackoffice\Develop\CDPBackoffice.root\CDPBackoffice\CDPBackoffice.DataAccessLayer.Tests\bin\Debug\CDPBackoffice.DataAccessLayer.Tests.dll\"" -mergebyhash -output:D:\projecten\udbdrm\source\CDP\CDPBackoffice\Develop\CDPBackoffice.root\CDPBackoffice\.sonar\coverage-report.xml -oldStyle
The solution does have several test classes, which run when executing them in Visual Studio and they do call source classes. Some of them fail some of them succeed.
Anyone who still has a clue on how to get test results?
Preferrably in sonar, but hey, as executing OpenCover with the call above puts the results in the coverage-report.xml and sonar uses that as input I'm fine with a working call ...
Apparently all I needed to add to the sonar-project.properties was this line:
sonar.gallio.runner=IsolatedProcess