etc. butler will then have the 341, 342, etc in the rows, and the test
names in the columns, with OK/FAILED in the cells, as you've done.
Once this is in place, let's create a tiny but opinionated driver
that knows how to update a branch *revision by revision* and drive
churn and butler from outside. This driver must get as input _just_
the build directory, and will have three things inside it.
So
$ whatever build/
Generates
build/
ensemble/
waterfall/
waterfall.html
But once you run
$ whatever build/
again, it will notice that there's already content inside it,
and will just update revision by revision the branch between
the latest revision in the waterfall and the current known
tip of the trunk.
With that in place, we can put this logic in a machine, and have it
rsyncing this content out into a public web server.
Do not use bzrlib, btw. Use bzr itself. We're not doing anything
fancy, and the command line API won't change.
[1]
This tool is doing three different things:
1. Running bzr update
2. Running churn
3. Converting churn output to html
The tool we discussed should do 3 only.
Let it take as input a directory full of churn output directories, and
produce the output based on the directory name. So we run it like:
$ butler.py watefall/ > waterfall.html
Given that within the waterfall dir one might expect:
/waterfall
some- test-name. out
other- test-name. out.FAILED
some- test-name. out
other- test-name. out
/341
/342
etc. butler will then have the 341, 342, etc in the rows, and the test
names in the columns, with OK/FAILED in the cells, as you've done.
Once this is in place, let's create a tiny but opinionated driver
that knows how to update a branch *revision by revision* and drive
churn and butler from outside. This driver must get as input _just_
the build directory, and will have three things inside it.
So
$ whatever build/
Generates
build/
ensemble/
waterfall/
waterfall.html
But once you run
$ whatever build/
again, it will notice that there's already content inside it,
and will just update revision by revision the branch between
the latest revision in the waterfall and the current known
tip of the trunk.
With that in place, we can put this logic in a machine, and have it
rsyncing this content out into a public web server.
Do not use bzrlib, btw. Use bzr itself. We're not doing anything
fancy, and the command line API won't change.
[2]
Please put a copy of pystache within the tree.
[3]
96 + <td>{{#failed}}<a href="{ {path}} "><strong> FAILED< /strong> </a>{{/ failed} } }Succeeded{ {/failed} }
97 + {{^failed}
We have the succeeded output as well. Let's offer it so people can
investigate differences.
It might also be better to have "ok" (lowercased) rather than "Succeeded", to make the
"FAILED" one much more outstanding.