I think I've got this in better shape. A new build is spinning now,
r7396.
The don't-build-doc-twice change that I put in was using a tweak I've
used a couple other places in the build, which breaks into procedural
javascript once in a while. We use rhino to hook up to the ant java
api, and make tasks dynamically. (We copied this from dojo.) Ant is a
pain to express "complex" conditionals in -- like "unless foo or bar"
-- so the rhino/scripting solution has been very useful so far.
It seems to have turned out that rhino is sensitive to whether a java
object was defined with "var mytask = lps.createTask('ant')" or just
"mytask = lps.createTask('ant')". In the first case, with var, the
parent build is kept alive while the child build executes. In the var-
less form, the parent build commits suicide as soon as it invokes the
child build. (This is different behavior on unix than on the mac, by
the way.)
In our case, the call to build dist-one was (very quietly) dying
after building the docs. It thus skipped building the tar.gz. When
the nightly-go.sh script went to push the devkit to the deployment
machine, it found no devkit, and failed.
FWIW, I want to improve the way our current build system notices and
reports errors other than megatest errors. We're pretty good at
noticing megatest failures, and failure to compile or build the LFC,
but we're not good at noticing and reporting errors after that.
-ben
On Nov 27, 2007, at 11:04 AM, Benjamin Shine wrote:
There are a couple things going on with the builds right now, as of
r7383. I point to the "post hoc, ergo propter hoc" logical
fallacy: http://en.wikipedia.org/wiki/Post_hoc_ergo_propter_hoc
1) Within docs/src, the doc build is weird. The code listings are
not included in the developer's guide, and the reference guide
seems to be skipped entirely.
2) I inserted a change to the main build.xml that tries to only
build the doc once in the dist-one target. This sets some flags and
prints some messages during the build that you haven't seen before.
However, this change may not be the cause of of the current build
weirdness.
3) The nightly build as a whole is broken. It's not clear exactly
what "broken" means, but, at least, labs.openlaszlo.org/trunk-
nightly is a 404. I see the problem in this part of the build
output, below -- the build could not deploy because there was no
*unix.tar.gz to push to the deploy machine. Why wasn't there a
tar.gz? That's my next target for investigation.
I am investigating these in the order of 3, 2, 1.
push-to-deploy:
[echo] Pushing from /home/svnbuild/builds/7378-openlaszlo-trunk
[echo] Push done.
[echo] mkdir done.
[exec] mv: cannot stat `/home/laszlo/public_html/labs/7378-
openlaszlo-trunk-unix.tar.gz': No such file or directory
[echo] mv done.
[exec] /home/laszlo/public_html/labs/7378-openlaszlo-trunk/
7378-openlaszlo-trunk-unix.tar.gz: No such file or directory
[echo] gunzip done.
[exec] tar: /home/laszlo/public_html/labs/7378-openlaszlo-
trunk/7378-openlaszlo-trunk-unix.tar: Cannot open: No such file or
directory
[exec] tar: Error is not recoverable: exiting now
[echo] ssh (exploder [but in a good way]) done.
BUILD SUCCESSFUL
Total time: 3 seconds
Buildfile: build.xml
-check-args:
init:
[echo] revision is 7378
[echo] build.name is 7378-openlaszlo-trunk
[echo] local war is file:/home/laszlo/public_html/labs/7378-
openlaszlo-trunk/lps-4.1.x/Server/lps-4.1.x
[echo] path.tag is http://svn.openlaszlo.org/openlaszlo/builds/
7378-openlaszlo-trunk
deploy:
[deploy] FAIL - Failed to deploy application at context path /
trunk-nightly
