[Buildbot-devel] GSoC: Initial thoughts on the Graphs and Data Charts Project
prasoon92.iitr at gmail.com
Tue Mar 17 06:44:46 UTC 2015
Well, I know the way I write might not be very clear. Anyway.
On Tue, Mar 17, 2015 at 11:15 AM, Mikhail Sobolev <mss at mawhrin.net> wrote:
> On Tue, Mar 17, 2015 at 02:45:02AM +0530, Prasoon Shukla wrote:
> Can you please provide examples of the data that are not inside Buildbot
> that you consider to provide graphs for?
As a solid example, I might want to measure the size of my generated
binaries, or to measure the number of function calls that a particular
unit-test makes, or to measure the total lines of comments in my code, or
to measure the how long a particular test runs for (and not the whole
Just to illustrate with an example, the test suite for LLVM is written
using google test framework <https://code.google.com/p/googletest/>. Then,
we cannot use metrics code to measure/count stuff within the LLVM test
suite. This is what I meant when I said that metrics code can not be used
So, for all non-trivial build data (e.g. timing a single unit test) we
cannot use metrics module.
Storing metrics data is a huge thing and it's not just about storing it in a
> database (be it the same as Buildbot uses or other), it's also about
> a fast access to various aggregations of the data and this is the part
> that I
> am the most concerned if the internal database is to be used.
Indeed. I completely agree with your assessment that we should leave the
storage to a dedicated service such as influxDB. I will have to read how
influxDB works before I can present a new storage scheme.
It would be nice if you provided examples for both kinds, then it'd be a bit
> easier follow your reasoning.
Yes, I should have done that. Anyway, here are two examples:
1. For time based test-statistic: Taking the example from above, say I want
to measure how long it takes a run a particularly time-consuming test. I
will make that one test run as a separate Step. So, buildbot will measure
the time taken for this Step automatically (since it measures times of all
steps). Then, we could have queried for this data over a number of builds
and plotted it. (But since we're planning on using influxDB, this will not
2. For non-time based test-statistic: If I want to measure the size of my
final build (for example, the size of generated binaries), I'll make a
small script that measure the size of the build directory and output it to
stdout. Then, I'll have this script run from within a new Step that can
record this build size from stdout and store it in the db.
> To make your points clearer, please try to give several specific examples:
> discussing general things are a bit more difficult, and it's easier to
> come to
> a misunderstanding (different people might understand different things
> those general names).
I will make sure to include examples from now on, wherever possible.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the devel