From: j vickroy on 10 May 2010 11:39 Jean-Michel Pichavant wrote: > j vickroy wrote: >> Stefan Behnel wrote: >>> j vickroy, 07.05.2010 20:44: >>>> I apologize if this is not the appropriate forum for a question about >>>> Hudson (http://hudson-ci.org/), but I did not know where else to ask >>>> and >>>> my web searches have not been fruitful. >>> >>> Certainly nice to read something about Hudson in this forum, which is >>> rare enough. It's seriously the greatest CI tool I've ever used, and >>> it works great with Python apps. >>> >>> >>>> "C:\Python26\Scripts\nosetests.exe --with-xunit --verbose" >>>> >>>> in the *Execute Python Script* subsection. >>> >>> The problem is that this isn't a "Python Script". I's a an >>> executable, native program. Use the "execute shell" build step instead. >>> >>> Stefan >>> >> Thanks for your reply, Stefan. >> >> When the above command >> >> "C:\Python26\Scripts\nosetests.exe --with-xunit --verbose" >> >> is moved to the "Execute shell" section of the job configuration page >> along with the following "tracer" command: >> >> #!python.exe >> print 'FOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO' >> >> their is still no indication the unit tests are run. >> >> Here is the output from the Hudson Console Output page >> >> ------------------------------------------------------------------- >> Started by user anonymous >> Updating svn://vm-svn/GOES data >> processing/trunk/GOES/13,14,15/SXI/level-1 >> At revision 3401 >> no change for svn://vm-svn/GOES data >> processing/trunk/GOES/13,14,15/SXI/level-1 since the previous build >> [workspace] $ python.exe >> C:\DOCUME~1\JIM~1.VIC\LOCALS~1\Temp\hudson2011616575490005324.sh >> FOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO >> [workspace] $ cmd.exe -xe >> C:\DOCUME~1\JIM~1.VIC\LOCALS~1\Temp\hudson902246697107326581.sh >> Microsoft Windows XP [Version 5.1.2600] >> (C) Copyright 1985-2001 Microsoft Corp. >> >> C:\Documents and Settings\jim.vickroy\.hudson\jobs\GOES 13-15 SXI >> Level-1 Products Generation\workspace>Recording test results >> Test reports were found but none of them are new. Did tests run? >> For example, C:\Documents and Settings\jim.vickroy\.hudson\jobs\GOES >> 13-15 SXI Level-1 Products Generation\workspace\level-1\nosetests.xml >> is 2 days 19 hr old >> >> Finished: FAILURE >> ------------------------------------------------------------------- >> >> As a side note, my Hudson "global" configuration page contains: >> >> cmd.exe >> >> in the "Shell executable" section and >> >> NOSEDIR >> C:\Python26\Scripts >> >> in the "Global properties" section. >> >> -- jv > Maybe something is missing on the machine hosting hudson, did you try to > execute nosetests.exe on that machine ? Hudson is running on my workstation (which also has python and nose installed). > I'm also confused with something, you do not provide nosetests with the > location of your package, assuming the current directory contains that > package (my guess). That is correct but see below ... > Instead of printing 'FOOO', try "import os ; print os.getcwd(); print > os.listdir(os.getcwd())" to know where you are exactly and if this dir > contains your python package. great suggestion ! This showed the current working directory to be one level above where I expected so that was definitely a problem so I changed my nose command, in the Hudson Job configuration Execute shell box, to be nosetests.exe --where=level-1 --with-xunit --verbose and saved the configuration change. This works as expected when run from a command shell in the Hudson current working directory for this Hudson job. Unfortunately, when "Hudson Build now" is performed, the Hudson Console output, for this job, is: ------------------------------------------------------------ Started by user anonymous Updating svn://vm-svn/GOES data processing/trunk/GOES/13,14,15/SXI/level-1 At revision 3403 no change for svn://vm-svn/GOES data processing/trunk/GOES/13,14,15/SXI/level-1 since the previous build [workspace] $ python.exe C:\DOCUME~1\JIM~1.VIC\LOCALS~1\Temp\hudson5273111667332806239.sh os.getcwd(): C:\Documents and Settings\jim.vickroy\.hudson\jobs\GOES 13-15 SXI Level-1 Products Generation\workspace os.listdir(os.getcwd()): ['level-1'] [workspace] $ cmd.exe -xe C:\DOCUME~1\JIM~1.VIC\LOCALS~1\Temp\hudson991194264891924641.sh Microsoft Windows XP [Version 5.1.2600] (C) Copyright 1985-2001 Microsoft Corp. C:\Documents and Settings\jim.vickroy\.hudson\jobs\GOES 13-15 SXI Level-1 Products Generation\workspace>Recording test results No test report files were found. Configuration error? Finished: FAILURE ------------------------------------------------------------ The second [workspace] section output (above) looks like cmd.exe is being executed with no parameters (i.e., without the "nosetests.exe --where=level-1 --with-xunit --verbose") parameter. Thanks for thinking about this; I realize how difficult it is to remotely troubleshoot a problem like this. -- jv > > JM > >
From: Stefan Behnel on 11 May 2010 02:35 j vickroy, 10.05.2010 17:39: > Unfortunately, when "Hudson Build now" is performed, the Hudson Console > output, for this job, is: > > ------------------------------------------------------------ > Started by user anonymous > Updating svn://vm-svn/GOES data processing/trunk/GOES/13,14,15/SXI/level-1 > At revision 3403 > no change for svn://vm-svn/GOES data > processing/trunk/GOES/13,14,15/SXI/level-1 since the previous build > [workspace] $ python.exe > C:\DOCUME~1\JIM~1.VIC\LOCALS~1\Temp\hudson5273111667332806239.sh > os.getcwd(): C:\Documents and Settings\jim.vickroy\.hudson\jobs\GOES > 13-15 SXI Level-1 Products Generation\workspace > os.listdir(os.getcwd()): ['level-1'] > [workspace] $ cmd.exe -xe > C:\DOCUME~1\JIM~1.VIC\LOCALS~1\Temp\hudson991194264891924641.sh > Microsoft Windows XP [Version 5.1.2600] > (C) Copyright 1985-2001 Microsoft Corp. > > C:\Documents and Settings\jim.vickroy\.hudson\jobs\GOES 13-15 SXI > Level-1 Products Generation\workspace>Recording test results > No test report files were found. Configuration error? > Finished: FAILURE > ------------------------------------------------------------ > > The second [workspace] section output (above) looks like cmd.exe is > being executed with no parameters (i.e., without the > "nosetests.exe --where=level-1 --with-xunit --verbose") parameter. No, what Hudson actually does, is, it writes your command(s) into a text file and runs it with the system's shell interpreter (which, unless otherwise configured, is "cmd.exe" on Windows). This assures the highest possible compatibility with the executed script. You can even use the shebang in Hudson's scripts that way, so that you can execute scripts in basically any scripting language. The likely reason why it doesn't find your test results is that you didn't tell it where to look. Put a wildcard path into the unit test config box that finds the XML files that nosetest writes. It's also best to tell nosetest where to put them explicitly using a command line option. Stefan
From: j vickroy on 11 May 2010 10:46 Thanks again, Stefan. My comments are below. Stefan Behnel wrote: > j vickroy, 10.05.2010 17:39: >> Unfortunately, when "Hudson Build now" is performed, the Hudson Console >> output, for this job, is: >> >> ------------------------------------------------------------ >> Started by user anonymous >> Updating svn://vm-svn/GOES data >> processing/trunk/GOES/13,14,15/SXI/level-1 >> At revision 3403 >> no change for svn://vm-svn/GOES data >> processing/trunk/GOES/13,14,15/SXI/level-1 since the previous build >> [workspace] $ python.exe >> C:\DOCUME~1\JIM~1.VIC\LOCALS~1\Temp\hudson5273111667332806239.sh >> os.getcwd(): C:\Documents and Settings\jim.vickroy\.hudson\jobs\GOES >> 13-15 SXI Level-1 Products Generation\workspace >> os.listdir(os.getcwd()): ['level-1'] >> [workspace] $ cmd.exe -xe >> C:\DOCUME~1\JIM~1.VIC\LOCALS~1\Temp\hudson991194264891924641.sh >> Microsoft Windows XP [Version 5.1.2600] >> (C) Copyright 1985-2001 Microsoft Corp. >> >> C:\Documents and Settings\jim.vickroy\.hudson\jobs\GOES 13-15 SXI >> Level-1 Products Generation\workspace>Recording test results >> No test report files were found. Configuration error? >> Finished: FAILURE >> ------------------------------------------------------------ >> >> The second [workspace] section output (above) looks like cmd.exe is >> being executed with no parameters (i.e., without the >> "nosetests.exe --where=level-1 --with-xunit --verbose") parameter. > > No, what Hudson actually does, is, it writes your command(s) into a text > file and runs it with the system's shell interpreter (which, unless > otherwise configured, is "cmd.exe" on Windows). This is not the behavior I am experiencing on my Windows XP Pro (Service Pack 3) workstation. If I do not specify "C:\WINDOWS\system32\cmd.exe" for "Manage Hudson | Configuration System | Shell | Shell executable", the "Console output" after a "Build now" is: ----------------------------------------------------- Started by user anonymous Updating svn://vm-svn/GOES data processing/trunk/GOES/13,14,15/SXI/level-1 At revision 3417 no change for svn://vm-svn/GOES data processing/trunk/GOES/13,14,15/SXI/level-1 since the previous build [workspace] $ sh -xe C:\DOCUME~1\JIM~1.VIC\LOCALS~1\Temp\hudson869574722591302824.sh The system cannot find the file specified FATAL: command execution failed java.io.IOException: Cannot run program "sh" (in directory "C:\Documents and Settings\jim.vickroy\.hudson\jobs\GOES 13-15 SXI Level-1 Products Generation\workspace"): CreateProcess error=2, The system cannot find the file specified at java.lang.ProcessBuilder.start(Unknown Source) at hudson.Proc$LocalProc.<init>(Proc.java:149) at hudson.Proc$LocalProc.<init>(Proc.java:121) at hudson.Launcher$LocalLauncher.launch(Launcher.java:636) at hudson.Launcher$ProcStarter.start(Launcher.java:271) at hudson.Launcher$ProcStarter.join(Launcher.java:278) at hudson.tasks.CommandInterpreter.perform(CommandInterpreter.java:83) at hudson.tasks.CommandInterpreter.perform(CommandInterpreter.java:58) at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19) at hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:584) at hudson.model.Build$RunnerImpl.build(Build.java:174) at hudson.model.Build$RunnerImpl.doRun(Build.java:138) at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:416) at hudson.model.Run.run(Run.java:1244) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:122) Caused by: java.io.IOException: CreateProcess error=2, The system cannot find the file specified at java.lang.ProcessImpl.create(Native Method) at java.lang.ProcessImpl.<init>(Unknown Source) at java.lang.ProcessImpl.start(Unknown Source) ... 17 more Recording test results Finished: FAILURE ----------------------------------------------------- Note Hudson is looking for "sh". This assures the highest > possible compatibility with the executed script. You can even use the > shebang in Hudson's scripts that way, so that you can execute scripts in > basically any scripting language. > > The likely reason why it doesn't find your test results is that you > didn't tell it where to look. Actually, Hudson is not finding the tests results because they are not being generated. There is no "nosetests.xml" file anywhere on my hard drive (except in the Recycle Bin from my explicit executions of the "nosetests.exe --where=level-1 --with-xunit --verbose" command). This is why I thought Hudson was not executing the above nosetests.exe command (specified in "*job* | Configure | Build | Execute shell | command". Put a wildcard path into the unit test > config box that finds the XML files that nosetest writes. It's also best > to tell nosetest where to put them explicitly using a command line option. > > Stefan > Thanks again for your continued interest. I quickly got Hudson to retrieve job source from our subversion repository so I thought it would be equally easy to get Hudson to run the unit tests, but that has proven to be difficult, and so far I do not know how to diagnose this since it seems there is no way to prevent Hudson from immediately deleting the temporary scripts it generates.
From: Stefan Behnel on 11 May 2010 11:11 j vickroy, 11.05.2010 16:46: > Stefan Behnel wrote: >> No, what Hudson actually does, is, it writes your command(s) into a >> text file and runs it with the system's shell interpreter (which, >> unless otherwise configured, is "cmd.exe" on Windows). > > This is not the behavior I am experiencing on my Windows XP Pro (Service > Pack 3) workstation. Then setting the "Shell executable" to "cmd.exe" will do the right thing here. >> This assures the highest >> possible compatibility with the executed script. You can even use the >> shebang in Hudson's scripts that way, so that you can execute scripts >> in basically any scripting language. .... although the shebang isn't really supported by cmd.exe, I guess ... >> The likely reason why it doesn't find your test results is that you >> didn't tell it where to look. > > Actually, Hudson is not finding the tests results because they are not > being generated. There is no "nosetests.xml" file anywhere on my hard > drive That's why I told you to configure nosetest to use an specific output path for the unit test file. > Thanks again for your continued interest. I quickly got Hudson to > retrieve job source from our subversion repository so I thought it would > be equally easy to get Hudson to run the unit tests, but that has proven > to be difficult, and so far I do not know how to diagnose this since it > seems there is no way to prevent Hudson from immediately deleting the > temporary scripts it generates. Which is ok, since it prints what it does during the script execution, and the scripts contain nothing more than what you typed in. Does nosetest produce an XML file when you call it manually from the command line? Is nosetest.exe in your PATH, so that the cmd.exe that Hudson starts can find it? Personally, I'd always step into the target directory before running a command, so I'd make the script cd level-1 nosetest.exe ... Stefan
From: j vickroy on 11 May 2010 11:26 Stefan Behnel wrote: > j vickroy, 11.05.2010 16:46: > > Stefan Behnel wrote: >>> No, what Hudson actually does, is, it writes your command(s) into a >>> text file and runs it with the system's shell interpreter (which, >>> unless otherwise configured, is "cmd.exe" on Windows). >> >> This is not the behavior I am experiencing on my Windows XP Pro (Service >> Pack 3) workstation. > > Then setting the "Shell executable" to "cmd.exe" will do the right thing > here. > > >>> This assures the highest >>> possible compatibility with the executed script. You can even use the >>> shebang in Hudson's scripts that way, so that you can execute scripts >>> in basically any scripting language. > > ... although the shebang isn't really supported by cmd.exe, I guess ... > > >>> The likely reason why it doesn't find your test results is that you >>> didn't tell it where to look. >> >> Actually, Hudson is not finding the tests results because they are not >> being generated. There is no "nosetests.xml" file anywhere on my hard >> drive > > That's why I told you to configure nosetest to use an specific output > path for the unit test file. OK, I will do this and report back. > > >> Thanks again for your continued interest. I quickly got Hudson to >> retrieve job source from our subversion repository so I thought it would >> be equally easy to get Hudson to run the unit tests, but that has proven >> to be difficult, and so far I do not know how to diagnose this since it >> seems there is no way to prevent Hudson from immediately deleting the >> temporary scripts it generates. > > Which is ok, since it prints what it does during the script execution, > and the scripts contain nothing more than what you typed in. Yes, and I am not seeing the nosetests.exe command listed anywhere in the Hudson console output. This is why I do not think Hudson is executing it. > > Does nosetest produce an XML file when you call it manually from the > command line? Yes it does. The exact same command (specified for the Hudson job) works perfectly from a Windows console. Is nosetest.exe in your PATH, so that the cmd.exe that > Hudson starts can find it? Yes, it is. "C:\Python26\Scripts" is in PATH and that is where "nosetests.exe" is. > > Personally, I'd always step into the target directory before running a > command, so I'd make the script > > cd level-1 > nosetest.exe ... OK, I will try this. > > Stefan >
First
|
Prev
|
Next
|
Last
Pages: 1 2 3 Prev: Cross-platform file paths Next: ConfigParser.get() defaults? |