Merge lp://qastaging/~jimbaker/pyjuju/generate-html into lp://qastaging/pyjuju/ftests
Proposed by
Jim Baker
Status: | Merged | ||||
---|---|---|---|---|---|
Approved by: | Gustavo Niemeyer | ||||
Approved revision: | 16 | ||||
Merged at revision: | 2 | ||||
Proposed branch: | lp://qastaging/~jimbaker/pyjuju/generate-html | ||||
Merge into: | lp://qastaging/pyjuju/ftests | ||||
Diff against target: |
499 lines (+461/-0) 7 files modified
f_tests.mustache (+24/-0) pystache/LICENSE (+20/-0) pystache/__init__.py (+8/-0) pystache/loader.py (+47/-0) pystache/template.py (+178/-0) pystache/view.py (+94/-0) waterfall.py (+90/-0) |
||||
To merge this branch: | bzr merge lp://qastaging/~jimbaker/pyjuju/generate-html | ||||
Related bugs: |
|
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Gustavo Niemeyer | Approve | ||
Review via email: mp+73924@code.qastaging.launchpad.net |
Description of the change
Implements waterfall.py, which writes to stdout an HTML summary of the results, using a waterfall style. This report links the output of failed and successful tests. This follows the review by Gustavo below. Note that the formatting is intentionally bare; it will be addressed in a future branch that adds CSS and expands f_tests.mustache in a minimal fashion.
A future stacked branch will implemented an opinionated driver that will manage working with bzr and driving churn; this driver will be called butler.py, to be in the spirit of that name.
To post a comment you must log in.
[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.