[Buildbot-devel] WebStatus ponderings

[Marcus Lindblom]

On 2010-01-06 17:25, Dustin J. Mitchell wrote:
> On Wed, Jan 6, 2010 at 4:14 AM, Marcus Lindblom<macke at yar.nu>  wrote:
>> 1. We need to write a testcase that does this. ;)
>
> Anyone want to have some fun with htmlunit?

I was thinking 'drunk monkey style' testing. Follow every link and make 
sure nothing is broken.

Checking every page for some known content OTOH, is a much grander goal, 
but yes, I suppose some form of web-based testing framework would help, 
esp with testimg forms and all.

Otherwise, we just need test data and some more test_webparts.py hacking.

>> 2. All pages that respond to parameters on the URL should have a help
>> text or a form where one can enter said data. It helps quite a bit when
>> testing these things. (The best way would be to handle this somehow via
>> HtmlResource, so that a page could describe it's options and have the
>> form be automatically generated and parsed back.)
>
> This would be pretty cool - much better than burying that info in the
> manual.  It doesn't necessarily need to be a web form, like the
> waterfall help, but that seems like a pretty easy way to set it up.

I was thinking that perhaps the manual should be bundled with webstatus 
somehow, anyway, Perhaps it suffices to link to the manual, if it's 
presented at a known local URL?

(Also, I'd love to see some TLC given to the manual's layout/style, 
similar to the new Python docs.)

>> 3. Someone (myself?) should hack together a better view of all the
>> changes that come in (they're only visible in waterfall, and there's no
>> concise list of them anywhere). Also, the ability to link incoming
>> changes/revisions to external web-views (hgwebdir.cgi, svnserve, viewvc,
>> trac, etc) would be cool&  integratey (;-P).
>
> I think that's what the "links" attribute of a Change is for, but this
> seems disused.  Perhaps it could be revived?

The problem is how to populate it properly. It feels wrong to insert 
this in the change hook, and there are a few places here and there where 
we list a revision without a change. (i.e. when we retrieve it in from 
the SourceStep.)

I like Benoit's proposal by adding a location to change. Then it would 
be up to another object to create an URL from location + change id, 
which necessarily needs user configuration. The same object would be 
used for any revisions ids the system comes up with, regardless of them 
coming from a change or not.

>> 3b. A Repository class would propbablt be a good thing to have, and
>> might suit what we're talking about with the multi-repo support. (I
>> haven't looked closely at those patches yet.)
>
> I had considered the very similar idea of a SourceManager in the
> one-oh work, and it might apply here, too.  A single object that knows
> everything about the source of the code.  It would provide
> pre-configured Source steps for you, could tell the web status which
> changes are which and what order they come in, calculate lists of
> changes and blamelists given an arbitrary two sourcestamps, etc.  It's
> a cool idea that just needs some further development!

Indeed. The notion of branches and 'latest' would work pretty well there 
too.

>> 4. Some sort of regexp->link to link "#xyz" entries in change comments
>> to bug issue pages would also be nice . A new param to webstatus taking
>> a regexp substitution and a jinja-filter ought to be enough
>> (i.e. we just write {{ c.comments|e|issue_links }} in the template where
>> issue_links is a python function applying the regex).
>
> Jinja is going to enable all kinds of goodness, isn't it?

;)

I'll see if I can get that thing working. It'd be cool to have.

For git/hg revision ids (which are 40 or 12 hex chars, respectively), 
the same thing would work with linking changes, actually. :)

Cheers,
/Marcus