Ant targets cannot be executed (better error message)

[Maarten Mulders <maarten@…>]

When running a build according to the following receipe, it fails.

The traceback is:

[ERROR   ] Internal error in build step 'copy-settings'
Traceback (most recent call last):
  File "/usr/lib/python2.5/site-packages/Bitten-0.6dev_r567-py2.5.egg/bitten/slave.py", line 263, in _execute_step
    step.execute(recipe.ctxt):
  File "/usr/lib/python2.5/site-packages/Bitten-0.6dev_r567-py2.5.egg/bitten/recipe.py", line 191, in execute
    ctxt.run(self, child.namespace, child.name, child.attr)
  File "/usr/lib/python2.5/site-packages/Bitten-0.6dev_r567-py2.5.egg/bitten/recipe.py", line 95, in run
    function(self, **args)
  File "/usr/lib/python2.5/site-packages/Bitten-0.6dev_r567-py2.5.egg/bitten/build/javatools.py", line 73, in ant
    xml_log = xmlio.parse(file(logfile.name, 'r'))
IOError: [Errno 2] No such file or directory: '/tmp/ant_logkBvjwO.xml'

The build receipe is:

<build xmlns:java="http://bitten.cmlenz.net/tools/java" xmlns:svn="http://bitten.cmlenz.net/tools/svn">
  <step id="checkout" description="Checkout source from repository">
    <svn:checkout url="url-masked" path="${path}" revision="${revision}" verbose="false" />
  </step>

  <step id="copy-settings" description="Copy some files needed to build and/or test">
    <java:ant file="build.xml" target="copy-settings" keep_going="false" />
  </step>

  <step id="build" description="Compile to byte-code">
    <java:ant file="build.xml" target="dist" keep_going="false" />
  </step>
</build>

[ole@…]

The error happens after the actual execution of the ant command. So you might check if the build directory contains the expected build result. If it does, ant seems to incorrectly handle the logfile parameter. If it doesn't, ant probably hasn't been run at all (path issues? permissions?)

[Maarten Mulders <maarten@…>]

That was a very helpful suggestion. Running bitten-slave -v shows

[DEBUG   ] ant exited with code 256

However, according to ​this post, Ant only has exit codes 0 or 1.

[ole@…]

Actually, no process should exit with an exit code greater than 255. Seems as if popen2.Popen3 shifts the exit code, making a 256 out of a 1. Anyway, something seems to be wrong with the ant call. I suppose you have tried to run the ant command on the console manually?!

[anonymous]

Well, actually, the ant build wasn't working. Yet, it might be a good idea to

a) not use exit codes > 255.

b) give the standard out / standard error output from ant, as it might help track down the problem.

[ole@…]

Couldn't agree more. Actually, most failing recipe commands do output their stderr into the logs, so I have no idea why ant behaves differently. Anyway, I'm glad to hear that you could solve your problem.

[Maarten Mulders <maarten@…>]

Maybe any of use should create a new ticket for displaying ant output in case of an exit code != 0, en declare this one invalid? Concerning the latter, I can only "leave (it) as new".

[osimons]

Replying to Maarten Mulders <maarten@…>:

Maybe any of use should create a new ticket for displaying ant output in case of an exit code != 0, en declare this one invalid?

Actually, this one has more information in it so I'm keeping this and closing #366 as duplicate.

[mgood]

Replying to ole@…:

Actually, no process should exit with an exit code greater than 255. Seems as if popen2.Popen3 shifts the exit code, making a 256 out of a 1.

Yes, the return code contains the exit code in the high bits and the low bits are then signal used to terminate the process. You should use os.WEXITSTATUS to extract the actual exit code: ​http://docs.python.org/library/os.html#os.WEXITSTATUS

[ole@…]

Replying to mgood:

You should use os.WEXITSTATUS to extract the actual exit code

Ah, thanks, I didn't know that. I guess the slave should output this specific value instead of the compound value (since it lables it "exit status" anyway).

[osimons]

Looking at the subprocess source (used for new implementation on #256), this module should return the correct code. From subprocess.py:

def _handle_exitstatus(self, sts):
    if os.WIFSIGNALED(sts):
        self.returncode = -os.WTERMSIG(sts)
    elif os.WIFEXITED(sts):
        self.returncode = os.WEXITSTATUS(sts)
    else:
        # Should never happen
        raise RuntimeError("Unknown child exit status!")

We may need to fix the other implementations (I haven't looked at it), but then again it is also a question of how long they will live if we bump requirement to Python 2.4.

[osimons]

Issues with trapping os execution errors, exit codes and more should now be fixed as part of [702].