FAILURE when a windows batch file runs another one with "call", UNSTABLE otherwise

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

FAILURE when a windows batch file runs another one with "call", UNSTABLE otherwise

Neofytos Chaitas
Hello!
I am a newcomer in hudson, I use its version "1.213" and I have 2
questions about its usage.

I let Hudson publish a report for my JUnit tests execution results and
I have also installed and activated the plugin for reporting
checkstyle results.
At the end I want to copy these results into hudson's workspace, so I
have written two simple batch files artifacts.cmd and
checkstyle-artifacts to do so.
In the configuration of my hudson job I execute as a last build step
artifacts.cmd which internally invokes checkstyle-artifacts.cmd.

a) When the latter is done with the "call checkstyle-artifacts.cmd"
command -so that the flow returns to artifacts.cmd-, the batch file
checkstyle-artifacts.cmd gets executed, the flow does not return to
artifacts.cmd (inspite of the use of "call") and hudson records test
results, does not invoke the checkstyle plugin at all(!) and reports
"FAILURE", although all building steps reported "BUILD SUCCESSFUL".
b) On the other hand, when artifacts.cmd invokes
checkstyle-artifacts.cmd directly without "call", the batch file
checkstyle-artifacts.cmd gets executed, since "call" has not been used
the flow does not return to artifacts.cmd, hudson records test
results, does invoke the checkstyle plugin and reports "UNSTABLE".
c) Finally when I remove the execution of the checkstyle-artifacts.cmd
from the artifacts.cmd and add it as a new build step to this hudson
job, hudson records test results, invokes the checkstyle plugin and
reports "UNSTABLE".

Question Nr 1: Is the execution of batch files use of "call" inside of
batch files discouraged by Hudson and instead of that the addition of
a build step with the execution of this batch file as a command
recommended?

By the way I thought that UNSTABLE (yellow colour) gets reported when
part of the tasks reported errors.
However all of my build steps report "BUILD SUCCESSFUL".
My job reports UNSTABLE ever since I introduced the step of the JUnit
tests execution, which throws some exceptions, report
[java] Java Result: 1
and at the end BUILD SUCCESSFUL.

Question Nr 2: Are these test execution exceptions the reason that my
overall hudson job reports UNSTABLE?

Thank you in advance for any hints!
Kind regards,
nchaitas

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: FAILURE when a windows batch file runs another one with "call", UNSTABLE otherwise

Clemens Anhuth
Neofytos Chaitas wrote:
> Question Nr 1: Is the execution of batch files use of "call" inside of
> batch files discouraged by Hudson and instead of that the addition of
> a build step with the execution of this batch file as a command
> recommended?

Hello,

we use "call" all the time in scripts run by Hudson. Hudson
simply spawns an instance of cmd.exe.

What can "kill" this approach is the use of the "exit" command
because it quits the current cmd.exe instance (not just the
currently executing script, unless you use "/b", too). Are you
using the "exit" command in the second script?



Bye bye

clemens

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: FAILURE when a windows batch file runs another one with "call", UNSTABLE otherwise

Neofytos Chaitas
Hi clemens,

thanks for your quick reply, the use of "exit" could be a good
explanation indeed, but this is not the case.
By the way, I also use "call" in another script run by hudson without
any problems.
The weird thing is that the checkstyle plugin for some reason doesn't
get invoked at all (normally it prints some output, when it gets
started) in case I add the "call" usage and I think this is the
reasdon hudson reports FAILURE at the end, although all build steps
reported BUILD SUCCESSFUL.

Kind regards
neo

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: FAILURE when a windows batch file runs another one with "call", UNSTABLE otherwise

Neofytos Chaitas
In reply to this post by Clemens Anhuth
I just found a blog entry of Kohsuke Kawaguchi
(http://weblogs.java.net/blog/kohsuke/archive/2006/11/diyorb_my_own_e.html)
where he mentions that "yellow means test failures" and therefore
answers my 2nd question.
However could someone tell me where to find more information about the
way hudson decides the overall build status?
I have defined some jobs that run windows batch files that execute xml
files and although some times (e.g. because of syntax errors in the
executed xml file) one build step fails (output: BUILD FAILED) hudson
reports at the end "finished: SUCCESS" and therefore blue.

Thank you for your help,
neo

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: FAILURE when a windows batch file runs another one with "call", UNSTABLE otherwise

Kohsuke Kawaguchi
Administrator
Neofytos Chaitas wrote:

> I just found a blog entry of Kohsuke Kawaguchi
> (http://weblogs.java.net/blog/kohsuke/archive/2006/11/diyorb_my_own_e.html)
> where he mentions that "yellow means test failures" and therefore
> answers my 2nd question.
> However could someone tell me where to find more information about the
> way hudson decides the overall build status?
> I have defined some jobs that run windows batch files that execute xml
> files and although some times (e.g. because of syntax errors in the
> executed xml file) one build step fails (output: BUILD FAILED) hudson
> reports at the end "finished: SUCCESS" and therefore blue.
It's based on exit code. If it returns 0, Hudson considers it as a success.

Your windows batch file is probably not propagating the error code
correctly to the caller.

> Thank you for your help,
> neo
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


--
Kohsuke Kawaguchi
Sun Microsystems                   [hidden email]

smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: FAILURE when a windows batch file runs another one with "call", UNSTABLE otherwise

Neofytos Chaitas
> It's based on exit code. If it returns 0, Hudson considers it as a success.
>
> Your windows batch file is probably not propagating the error code correctly
> to the caller.
>

Thanks! I just added at the end of my batch file the command:
exit /b %EXIT_CODE% (I set EXIT_CODE to 0 or not to reflect success or
not respectively)
and although EXIT_CODE is not 0 Hudson reports SUCCESS. If I remove /b, namely:
exit %EXIT_CODE% Hudson reports FAILURE, but this will end my CMD.EXE,
when executing the batch file from the command line, and of course I
don't want the CMD window to disappear every time I run it from there.

I also tried to set directly the ERRORLEVEL env. variable to 1
(although it is not considered to be a good practice; s.
http://batcheero.blogspot.com/2007/07/never-set-errorlevel.html) and
Hudson still reports SUCCESS.

What am I missing???

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: FAILURE when a windows batch file runs another one with "call", UNSTABLE otherwise

Clemens Anhuth
Neofytos Chaitas wrote:

>> It's based on exit code. If it returns 0, Hudson considers it as a success.
>>
>> Your windows batch file is probably not propagating the error code correctly
>> to the caller.
>>
>
> Thanks! I just added at the end of my batch file the command:
> exit /b %EXIT_CODE% (I set EXIT_CODE to 0 or not to reflect success or
> not respectively)
> and although EXIT_CODE is not 0 Hudson reports SUCCESS. If I remove /b, namely:
> exit %EXIT_CODE% Hudson reports FAILURE, but this will end my CMD.EXE,
> when executing the batch file from the command line, and of course I
> don't want the CMD window to disappear every time I run it from there.
>
> I also tried to set directly the ERRORLEVEL env. variable to 1
> (although it is not considered to be a good practice; s.
> http://batcheero.blogspot.com/2007/07/never-set-errorlevel.html) and
> Hudson still reports SUCCESS.
>
> What am I missing???

Neofytos,

you can add "echo" and "pause" statements to provide information
about the error and the exit code that the batch will be exiting
with. When run from Hudson the "pause" will be immediately
satisfied by Hudson feeding CRLF or so into the stdin stream of
the cmd.exe process.

Also, to avoid having your carefully set up console process
being closed you could make it so that you can run the scripts
via Windows Explorer. This might require that they set the
working directory explicitly as required by the scripts. I use
this to always set the working directory to the path of the script:

pushd "%~dp0"

And I make sure that I call popd at the end of successfully
running the script (in case of error cmd.exe gets closed via
"exit" anyway).



You can also conditionally use "exit" or "exit /b", the
condition would be wether the script got executed by Hudson or
not (you can check for the existence of several environment
variables that Hudson sets in the processes it spawns, use "set"
in a script called by Hudson and inspect the output for possible
candidates).

I suggest to use "exit /b" only when the return code does not
matter, and when you are on the console, and "exit" in all other
cases. I don't recall the specifics of calling "exit /b" in a
script CALLed by another script, but I seem to recall to find
surprising behavior there too. (I don't like surprises of that
kind.)

(I would also suggest to get away from any non trivial scripting
with cmd.exe because the scripting is so primitive that you'll
probably waste a lot of time creating, bugfixing and maintaining
scripts than with any other scripting language. After battling
cmd.exe scripting for a few weeks a few months ago I switched
over to Python, which back then was completely new to me, and
never regretted to have a full fledged, feature rich scripting
language that allows writing cross-platform scripts.)



Bye bye

clemens

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: FAILURE when a windows batch file runs another one with "call", UNSTABLE otherwise

Neofytos Chaitas
Thanks Clemens for your great help.
The problem was that at the end of my script file I was unsetting all
temporary env. variables I had defined, since I don't find a good
practice, when batch files do not clean up the env. variables they
define internally (That's why I used "call script2.cmd" inside of
script1.cmd (s. Question Nr. 1) in order to return back to script1.cmd
and unset all its env. variables. By the way, am I right or is it
common to leave them set?). The last "set MY_TMP_ENV_VARIABLE=" was
setting the ERRORLEVEL to 0 and therefore Hudson was reporting
SUCCESS.
What I do now is follow your Hudson env. variables tip, that means I
add at the end of the batch file (after unsetting all temporary env.
variables):
if NOT x%HUDSON_COOKIE%==x exit %EXIT_CODE% (after running my ant task
and before starting unsetting my env. variables I had set: set
EXIT_CODE=%ERRORLEVEL%)
That way Hudson gets the exit code he needs and the batch file does
not close CMD.EXE when executed from the command line.

Nice tip, Clemens,
thank you very much!

PS: My Question Nr. 1 is still open, by I have actually no problem
with that, since I replaced "call script2.cmd" inside of script1.cmd
by adding a new build step "script2.cmd" in this hudson job. However,
regardless of my workaround, it may be an issue, that the checkstyle
plugin was never invoked (actually it never produced any output!) at
the end of a hudson job, only as long I used "call script2.cmd" inside
of script1.cmd. This hudson job was consisted of steps that all
reported BUILD SUCCESSFUL.and still hudson reported FAILURE as overall
build status. I think this behaviour is typical when the plugins
configuration at the end of the job has errors, which also agrees with
the fact that the checkstyle plugin was not executed. But how could
the usage of "call" influence that? As I mentioned in my first
posting, everything worked fine (hudson's overall build status
SUCCESSFUL) as soon as I removed the word "call" when executing
script2.cmd inside of script1.cmd, namely "call script2.cmd" did NOT
work, "script2.cmd" worked! Note that both scripts return exit code 0,
because of their env. variables unsetting at their end.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: FAILURE when a windows batch file runs another one with "call", UNSTABLE otherwise

Kohsuke Kawaguchi
Administrator
Windows batch file is really crippled and with all kinds of problems.

I'd highly recommend using a shell script (through cygwin or MKS),
Perl, or that sort of things.

2008/7/2 Neofytos Chaitas <[hidden email]>:

> Thanks Clemens for your great help.
> The problem was that at the end of my script file I was unsetting all
> temporary env. variables I had defined, since I don't find a good
> practice, when batch files do not clean up the env. variables they
> define internally (That's why I used "call script2.cmd" inside of
> script1.cmd (s. Question Nr. 1) in order to return back to script1.cmd
> and unset all its env. variables. By the way, am I right or is it
> common to leave them set?). The last "set MY_TMP_ENV_VARIABLE=" was
> setting the ERRORLEVEL to 0 and therefore Hudson was reporting
> SUCCESS.
> What I do now is follow your Hudson env. variables tip, that means I
> add at the end of the batch file (after unsetting all temporary env.
> variables):
> if NOT x%HUDSON_COOKIE%==x exit %EXIT_CODE% (after running my ant task
> and before starting unsetting my env. variables I had set: set
> EXIT_CODE=%ERRORLEVEL%)
> That way Hudson gets the exit code he needs and the batch file does
> not close CMD.EXE when executed from the command line.
>
> Nice tip, Clemens,
> thank you very much!
>
> PS: My Question Nr. 1 is still open, by I have actually no problem
> with that, since I replaced "call script2.cmd" inside of script1.cmd
> by adding a new build step "script2.cmd" in this hudson job. However,
> regardless of my workaround, it may be an issue, that the checkstyle
> plugin was never invoked (actually it never produced any output!) at
> the end of a hudson job, only as long I used "call script2.cmd" inside
> of script1.cmd. This hudson job was consisted of steps that all
> reported BUILD SUCCESSFUL.and still hudson reported FAILURE as overall
> build status. I think this behaviour is typical when the plugins
> configuration at the end of the job has errors, which also agrees with
> the fact that the checkstyle plugin was not executed. But how could
> the usage of "call" influence that? As I mentioned in my first
> posting, everything worked fine (hudson's overall build status
> SUCCESSFUL) as soon as I removed the word "call" when executing
> script2.cmd inside of script1.cmd, namely "call script2.cmd" did NOT
> work, "script2.cmd" worked! Note that both scripts return exit code 0,
> because of their env. variables unsetting at their end.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>



--
Kohsuke Kawaguchi

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]