[Buildbot-devel] GSoC: Initial thoughts on the Graphs and Data Charts Project
Prasoon Shukla
prasoon92.iitr at gmail.com
Tue Mar 10 19:22:48 UTC 2015
@Mikhail:
I hadn't incorporated metrics in my idea because I thought it wasn't
complete. Anyway, I went through that ticket and now I can see that metrics
module already has support for collecting data however it cannot yet:
a. Store the data properly (http://trac.buildbot.net/ticket/2032),
b. Retrieve the stored data in a structured format (We still need to rely
on grep).
So, the minimum possible requirement to using the metrics module would be
to actually implement these two features first. I think that I should be
able to accomodate these two tasks in my project as well since the actual
graph-and-charts project isn't very big in itself. This will, however, mean
that no one would be able to take the metrics project separately (which
shouldn't be a problem - no one has expressed an interest in that project
yet).
Would this be acceptable? I mean, should I go ahead and count these two
tasks as part of my project?
@Pierre:
Thanks for the link. I took a look at it and found that buildbot_travis
implements its own version of shell.ShellCommand which can process the
output of commonly used test frameworks such as nose and trial. They're
processing the output by using a couple of regexes to exctract useful stats
from the test logs. However, this is not something we can do since we need
to support all possible test frameworks for all possible languages and we
cannot possibly go about writing a regex for all such cases. But, as you
said, this is a good representation of something that people might want to
have. (As an aside, test frameworks often only reveal very high level build
statistics such as the number of pass/fail/skipped test and so, perhaps
this is not such a good representative after all :D)
Anyway, my idea is simply an extension of what is being done in
buildbot_travis - instead of us matching patterns against a variety of
testing frameworks, we want the the users to provide us the extracted
information from whatever form of test they might be able to conceive. It
is a very powerful scheme, IMO, and like all powerful things, it forces the
user to do some of the heavy lifting which in this case translates to
writing a script.
So, to reiterate, I would like to know whether I can add the improvements
to the metrics module as a part of my project. Also, I would like to know
your opinions on the stuff I already metioned in my initial post.
Once it is decided whether I should add support for metrics or not, I'll be
able to put forward a more solid plan.
On Tue, Mar 10, 2015 at 1:15 AM, Pierre Tardy <tardyp at gmail.com> wrote:
>
>
> Le lun. 9 mars 2015 à 20:19, Mikhail Sobolev <mss at mawhrin.net> a écrit :
>
>> Hi Prasoon (I hope this is the correct first name),
>>
>> I'd need to go more thoroughly through the ideas you listed, however first
>> thing I noticed that you do not mention 'metrics' feature of Buildbot
>> that was
>> implemented quite some time.
>>
> There is also some prior art in buildbot_travis eight version:
>
>
> https://github.com/isotoma/buildbot_travis/blob/master/buildbot_travis/steps/create_steps.py#L44
>
> So this should be a good example of what people want, so that would be a
> good thing to try and see what it looks like.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://buildbot.net/pipermail/devel/attachments/20150311/62818ef0/attachment.html>
More information about the devel
mailing list