I added a build step for my project in teamcity which consists on using the plugin Parasoft Findings to publish an XML report of all the code violations. the problem is that teamcity is failing to parse XML report. It says there is an unexpected report format and to see log (which I couldn't find).
I already checked the report location pattern which is right. I don't use SOAtest but C++ test so I only put "Parasof analyzers 10.x" for the report type
I'm sorry but you did not provide any additional details regarding your question and it's hard to help you.
Please, provide:
error message
your configuration of build step and version of TeamCity and C++test
command line used to start C++test ( if you are using variables,
replace variables with real values used in your run)
By log I think, you should check your build step log, and provide us the right content.
You can find such logs on two different ways:
You can download it by clicking "Download full build log" on build
log page (Recommended).
Try to find the raw output from the build agent by looking in the
agents logs directory, for example in
c:\TeamCity_dir_agent\logs\teamcity-build.log
Following article from JetBrains' TeamCity manual might good point to start
Edit:
Parasoft updated the plugin which fixed the issue:
https://plugins.jetbrains.com/plugin/9949-parasoft-findings
I have the same issue. Error messages in build log:
Unexpected report format: <path-to>\report.xml. See log for details.
Failed to parse XML report
Failed to parse XML report
Step test results (Parasoft Findings) failed
teamcity-agent.log and teamcity-build.log are having no entries within this build step because there is no piece of code which would write that into during this error case.
Edit/Workaround:
In the report the node <ExecutedTestsDetails> must be below the node <Exec>. The node still has the right indendation but it is at the same level as <Exec>. The xsl of TeamCity Plugin works perfectly if you fix the report xml manually.
To make it work you can add the Build Feature "File Content Replacer" like that:
Regex: (?s)(<ExecutedTestsDetails.*?<\/ExecutedTestsDetails>).*?(<Exec.*?>)
Replace with: $2 $1
Related
I have installed Jasper reports server 6.3.0 along with Icinga-reporting (from the git repo)
I can run sample reports without any problem, but when I try and run specific Icinga reports which have a time period they fail and error out with;
Errors were encountered when compiling report expressions class file: org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed: calculator_Service32activity32report32in32given32time_1484836971660_629753: 13: unable to resolve class org.icinga.reporting.DateHelper # line 13, column 1. 1 error .
If you want the full stack trace please leave a comment and I will update the question.
I have done lots of googleing and have found afew links which reference the issue, but no one has actually said in (still valid) steps how to resolve the problem.
This looks like the closest fit - but the info referenced no longer exists (The entire Icinga wiki has been removed!)
I also found this but it links to very old jars which I've included in the WEB-INF/lib path but still getting the same error.
If I run a report that does not have a time/date then the report works (So I know Jasper is actually working)
If you need any additional info please leave a comment & I will update the question.
The problem turned out to be cause by icinga-reporting.jar missing from the tomcat WEB-INF/lib/ folder.
When you build icinga-reporting.jar it includes the org.icinga.reporting.DateHelper functions that where the cause of the original error.
When I installed the reporting the post deployment scripts where run and I'm sure it had copied the .jar file to the correct path, but when I later searched for it it was missing...
Manually copying the file to the correct path resolved the issue & reports with a time/date element now run without errors.
We use Coverity's free scanning service for free and open source projects. We have not been able to utilize the service for the last two months or so. Prior to the service failures, we had half-a-dozen or so good analysis.
Submitting a scan results in:
Last Build Status: Failed. Your build has failed due to the following reason. Please fix the error and upload the build again.
Error details: :Failed to retrieve tar file
Coverity is very good about providing copy/paste directions, and we have copied/pasted them religiously. We verified there are no build errors, and we verified the build ends with "131 C/C++ compilation units (100%) are ready for analysis" and "The cov-build utility completed successfully".
We've tried to resolve the issue by verifying things from this generic solution provided in a "failed email" response from the service. We verified or performed all of them except number four.
We did not perform number four because Coverity's documentation is horrible (its the exact opposite of their awesome scanning service). Because there's no instructions or RTFM to read, we have no idea which knobs should be turned for bin/cov-configure. We don't want to mess with it since it worked in the past.
We also tried the following:
using the web submission form and browser
using curl from the command line
packaging cov-int/ in a tarball
packaging cov-int/ in a zip file
using all lowercase for the project name
capitalizing the first letter of the project name
We always get the same message ("Failed to retrieve tar file"), even with a ZIP file. Recall that prior to about 6 weeks ago, everything was working fine.
What is the secret to uploading a file to the service? What has changed in the last six weeks or two months?
After contacting the coverity support we just received the following answer and we could successfully submit a build. Seems there was some hickup on the coverity side.
"This was due to some behind the
scenes issues on our end – nothing interesting,, but it is back up and
running now. Thanks for your patience".
So, the key element here is hidden artefacts, also known as those that appear under .teamcity/ part of the build artifacts.
Some context:
We currently run dotCover over our NUnit Test step to report on our test coverage. This places a compilation of the results in a file named CoverageResults.xml under .teamcity/.NETCoverage/. This is the file I would like to accces so we can mine if for some data and send it to a gecko board.
Now, so far, we can successfully get at artifacts not in this part of the directory (such as the result of the build when we output it, etc) using the advised methodology. The problem only occurs when accessing this hidden directory.
The other odd things is the response: a 302 Temporarily Moved.
For reference, my link looks like: (in powershell btw)
"http://{0}:{1}#{2}/guestAuth/repository/download/{3}/.lastFinished/.teamcity/.NETCoverage/CoverageReport.xml" -f $serverURl, $gUName, $gPassword, $buildType
Does anyone have any advice on accessing hidden artifacts? Where else this data could be drawn from (we've found nothing on system variables for this)?
Note: We are already aware that these artifacts are not produced till the build step completes. We are doing this after the fact against a completed build, not during the Build Job itself.
If you add this in the Artifact Paths field it will attach the report as a build artifact once the build has completed
%system.teamcity.build.tempDir%\**\CoverageReport.xml
Hope this helps
Leaving the solution we came up with in case it can be help to anyone else:
In the end, we never got the nitty-gritty of the why but in short, using the in URL authentication with Powershell's Invoke-WebRequest does not work. It appears this is culled from the request created or some such but we went in another direction so I cannot comment much more on this.
What we did do was instead, use cURL. This does not do whatever Powershell does so we simply broke this down into two steps on the Team City Build. A command line step to use cURL to download the file and place it in a temporary directory and the a Powershell step afterwards to get the file and do what we wanted to do.
I am facing a problem with Hudson and NUnit testing. When trying to publish the Test Result Report for NUnit, the option in Hudson, i.e., "Publish NUnit Test Result Reports", is creating a problem. I am unable to provide the Path of the already-created XML file under the workspace folder of the Job. When I set the path of my file, i.e., "nunit-result.xml" and run the job, it throws an error:
"No test report files were found. Configuration error?"
Can anyone please help me out?
Thanks in advance.
Check the the beginning of the log where the clone is made. Sometimes when you have the "Enable concurrent builds" option it triggers another build in a different workspace called your-project-name#2/source and that's why it can't find the reports
We recently upgraded CruiseControl.Net 1.4.2 to 1.5.7256.1. To our dismay the nice nunit results page that had previously been there had disappeared. All we get now is a build log with the verbose output from command line of our build.
After some research we discovered you can log into "Dashboard Administrator" from the main ccnet dashboard page and install the NUnit package. However, this did not change the output of our builds to include a NUnit result page.
Is there something extra we need to do here to have our output displayed? Any help would be greatly appreciated. I don't goto stack overflow until I've exhaustively searched on Google. I'm surprised no one else is confused or complaining about this.
FYI, we are merging our nunit XML output in the project configuration.
I'm not used to the Dashboard Administrator stuff, but you can edit the dashboard.config manually. Opposite to earlier versions CCNET version 1.5 comes with a naked configuration file.
Alternatively you may simply replace the configuration file with your 1.4 dashboard.config.
Possible duplicate of Cruise Control .net: Using packages and showing NUnit results
Don't merge manually if you use the nunit task
Edit the dashboard.config and the ccservice.exe.config files to add the nunit xsl files. Restart IIs.
Check that the Iis user has been granted access to the dashboard dir.