[Buildbot-devel] GSoC: Initial thoughts on the Graphs and Data Charts Project

[Prasoon Shukla]

By the way, I am looking into influxDB right now.
Mikhail wrote:

> * identify what kind of metric "entities" need to be ipmlemented beside
> those
>   that already exist and implement them

I am confused as to what these metric entities are? Are these objects that
generate build statistics (like a build or a builder)?

On Tue, Mar 17, 2015 at 12:14 PM, Prasoon Shukla <prasoon92.iitr at gmail.com>
wrote:

> 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
>> and
>> 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
> build).
>
> 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 outside buildbot.
>
> 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
>> providing
>> 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
> be done.)
>
> 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
>> under
>> those general names).
>>
>
> I will make sure to include examples from now on, wherever possible.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://buildbot.net/pipermail/devel/attachments/20150317/5861f564/attachment.html>