Sysprogs forums › Forums › VisualGDB › fault with SYSPROGS_TEST_REPORTING_PIPE when I try and build my project from the
- This topic has 5 replies, 2 voices, and was last updated 7 years, 10 months ago by support.
-
AuthorPosts
-
January 17, 2017 at 15:58 #10101BrewerymanParticipant
Hi,
I’m rewording this post with the question at the beginning rather than after the background info:
Why am I getting a reference to a fault with SYSPROGS_TEST_REPORTING_PIPE when I try and build my project from the command line?
Also what can I do to enable me to successfully make the project and run the tests from the command line in order to validate the project via Jenkins.I’ve been successfully running unit tests within my Visual GDB IDE and the next target is for me to link this through in to Jenkins.
In order to prove that the system can work correctly I do believe that I should be able to reach a situation whereby I can
- check out my project to a folder on a Linux box (which has had “apt-get install cpputest” run previously)
- go to the project folder
- type “make all”
- execute .Debug/outputFileName -o junit
As I understand this technique should then create an xml file within Debug/ for each test group.
I was initially struggling as the testframework files I had previously installed were not being found.
I therefore generated a workaround for the time being by copying across the relevant TestFramework folder across prior to making the project.
This has succeeded in the make option, but I then struggle with the next stage.If I run
.Debug/outputFileName -o normal
then the first line of the output states
SYSPROGS_TEST_REPORTING_PIPE not set. Cannot report test status!Is this referring to a parameter which I require in order to force the output to appear in a certain location?
Alternatively is there a particular method recommended for going to offer CPPUTEST continuous integration once the project has been configured in VisualGDB?
ThanksAndy
January 17, 2017 at 17:48 #10110supportKeymasterHi,
This message appears because VisualGDB uses a special mechanism to get structured output from the tests that can be properly displayed in Visual Studio. This involves creating a temporary pipe and setting an environment variable so that the application can find this pipe.
If you want to run VisualGDB unit tests from Jenkins, we would recommend running the VisualGDB executable with the /runtests argument as shown at the end of this tutorial. This will automatically configure everything and save the output in an XML file.
If you want to run your tests without VisualGDB, you would need to manually modify the project to build with the regular CPPUTest instead of the version that comes with VisualGDB.
January 17, 2017 at 18:30 #10112BrewerymanParticipantThanks – I’ll have a look at those options. I do believe that we should be able to come up with a solution based upon that.
I’m not sure the /runtests option will work for us as we are running Jenkins on a Linux box rather than windows, though I will put some more effort into finding the resident cpputest solution on our Linux box. I have installed this using apt-get install but I’ve yet to find where it has hidden itself.
Thanks for the guidance,
Andy
January 18, 2017 at 18:52 #10124supportKeymasterHi,
If you are running Jenkins on Linux, you would need to use the unmodified version of CppUTest. The exact steps to use it are different on different Linux distros, so searching online for <your Linux distro> cpputest should normally get relevant instructions.
If this helps, we could also add a command-line switch that will disable VisualGDB-specific test reporting so that you could run your tests on Linux by adding something like “-standalone” to the command line. Let us know if you would prefer this.
January 19, 2017 at 16:31 #10132BrewerymanParticipantThankyou for your feedback. It looks like I do need to continue with working towards getting cpputest installed separately on my CI machine and then modifying the makefile to point to the local version of the cpputest files when it builds under Linux.
If a new command line option might enable us to turn off the VisualGDB testing then I think that would benefit in that it would avoid the error message I was getting and would make this current process easier to manage under automated conditions.
Cheers
AndyJanuary 19, 2017 at 22:22 #10139supportKeymasterHi,
We have double-checked the sources of CppUTest and the solution is actually much simpler.
Please comment the ‘return’ line after the following line in SysprogsTestHooks.cpp:
fprintf(stderr, "SYSPROGS_TEST_REPORTING_PIPE not set. Cannot report test status!\n");
This will let the tests proceed even when the VisualGDB-specific reporting mechanism is not set, so you won’t need any special command line.
-
AuthorPosts
- You must be logged in to reply to this topic.