Multiple build sdt entries for each build will result in duplicated
build context information stored on Hackystat server.
Still using the old example, under flat scheme, 4 entries will be sent.
They are:
Entry1: buildSDT
result = failed
failure type = checkstyle
failure message = "file 1 line longer than 100
runtime = 0000000001
additional information =
(startTimeMillis=11001111;
endTimeMillis=1111002222;
project=hacky2004-all;
configuration=Hackystat-JPL;
startType=CC-auto;
checkstyleRunned=true;
compilationRunned=true;
unittestRunned=true;
failureModuleName=hackyKernel)
Entry2: buildSDT
result = failed
failure type = junit
failure message = assertion failed
runtime = 0000000001
additional information =
(startTimeMillis=11001111;
endTimeMillis=1111002222;
project=hacky2004-all;
configuration=Hackystat-JPL;
startType=CC-auto;
checkstyleRunned=true;
compilationRunned=true;
unittestRunned=true;
failureModuleName=hackyKernel)
Entry 3 ...
Entry 4 ...
Basically, all build context information is duplicated. The situation is
not exactly like what we have for junit sensor or locc sensor, where
there is no duplicated information among sdts for the same batch.
When doing analysis, we have to assume that build context information in
all build sdts are exactly the same.
If this amount of duplicated information is ok, then I will go ahead and
change the persistence scheme.
Thanks.
Cedric
----- Original Message -----
From: Philip Johnson <[EMAIL PROTECTED]>
Date: Sunday, February 6, 2005 7:53 am
Subject: Re: [HACKYSTAT-DEV-L] SDT representation of build data,
evolutionary SDTs
> --On Saturday, February 5, 2005 10:51 PM -1000 "(Cedric) Qin
> ZHANG"
> <[EMAIL PROTECTED]> wrote:
>
> > I want to use the existing flat persistence scheme (much
> simpler), but I
> > just don't know how. Can somebody help me?
>
> Hi Cedric,
>
> This is exactly like the situation with FileMetrics, where we want
> to be
> able to aggregate together a set of individual FileMetrics records
> in order
> to represent the size of a complete system. What we do in that
> case is
> include a "runtime" attribute that is used to identify that a set
> of
> FileMetric sensor data (each with distinct tstamp values) were
> generated
> from a single invocation of the tool (LOCC). You can follow the
> same
> approach to resolve your problem.
>
> BTW, under this scheme, in order to count the number of builds in
> a given
> day, you just count up the number of distinct "runtime" values.
>
> Now, this does require us to rethink the semantics of the Build
> SDT. We
> probably want to make "runtime" a required field, and we want to
> modify the
> specification to say that a single invocation of a Build tool can
> result in
> multiple Build sensor data being generated, each one describing a
> distinct
> result from the build. That seems like a nice improvement to the
> current
> specification.
>
> One other thing. While we're hacking the Build SDT, could you
> please add a
> field that represents the top-level target(s) that were invoked?
> For
> example, it's interesting to know in the case of Hackystat whether
> the
> build failed (or succeeded) as a result of running:
>
> ant quickStart
>
> vs.
>
> ant freshStart junitAll
>
> It also turns out that knowing the top-level target passed to
> "make" (and
> the results) is very useful in Mike's HPC research.
>
> Let us know if you see additional problems.
>
> Cheers,
> Philip
>
>
>
>
>
>
>
>
>
