[prev in list] [next in list] [prev in thread] [next in thread] 

List:       mondrian
Subject:    [Mondrian] Re: Hudson
From:       Aaron Phillips <aphillips () pentaho ! com>
Date:       2009-02-02 21:59:55
Message-ID: 1233611995.20539.57.camel () aaron-linux
[Download RAW message or body]

[Attachment #2 (multipart/alternative)]


My 2 centavos are as follows:
-Aaron

On Mon, 2009-02-02 at 13:29 -0800, Julian Hyde wrote:
> Build guys,
>  
> Now we have Hudson online, I have a few questions about Hudson:
>  
> 1. We still have one failure. How important is it to fix this? (I.e.
> is the failure preventing anything from happening, such as generation
> of binaries or code coverage?)

It is important if you want to have notifications and code coverage.
Notifications (email) happen when you go from stable to unstable and
vice-versa, so if the project remains unstable (aka tests are failing),
then there will be no notifications.  This is the typical configuration,
but we can change this to notify on every unstable build.
>  
> 2. The cobertura report
> ( http://ci.pentaho.com/job/mondrian/lastStableBuild/cobertura ) is no
> longer available. What's up there?

Cobertura reports for some reason are only generated when there are no
failing tests which explains why it has disappeared.

>  
> 3. How difficult would it be to test one or more other configurations?
> Important aspects of the configuration are JDK { jdk14, jdk15,
> jdk16 }, database { MySQL, Derby, Oracle, ... }, native evaluation
> { false, true }. One other configuration (say (jdk16, Derby,
> native-eval=false)) would give us good extra coverage.

Pretty sure that it will not be trivial to do this.  Hudson does have a
notion of "matrix" builds which allow for manipulation of axes like you
mention, however I'm sure this will be a time-consuming effort.  We also
have the issue of h/w resources which will have to be bolstered greatly
for this.
>  
> 4. The 'megatest' shell script tests multiple configurations. How
> difficult would it be to run a shell script from hudson? If that's
> possible, megatest could be our long regress, and we could just have
> one config for the short regress. (Yeah, I used to run this on
> marmalade, but interpreting the build results was a manual process and
> I got behind in this process.)

I would recommend a separate Hudson slave to run megatest on a regular
but nearly as frequent interval.  How difficult?  I personally don't
know as I've never run them before.  But basically anything you can do
on a command line can be wrapped in a Hudson job, so it is very
possible.
>  
> 5. What are your opinions about having a long & a short regress? If
> so, is the ideal time for the short regress?

No opinion on this.  I think the answer will be constrained by the
amount of available CPU.
>  
> By the way, there are a couple of options for making the short regress
> faster: 1. Run against Oracle-XE (it's free-as-in-beer and easy to
> install on Linux) not MySQL, 2. Don't generate code coverage.  (I note
> that it's ~1 hr right now, whereas build+regress against Oracle takes
> ~7 minutes on marmalade.)
>  
> Julian

[Attachment #5 (text/html)]

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
  <META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
  <META NAME="GENERATOR" CONTENT="GtkHTML/3.18.3">
</HEAD>
<BODY>
My 2 centavos are as follows:<BR>
-Aaron<BR>
<BR>
On Mon, 2009-02-02 at 13:29 -0800, Julian Hyde wrote:
<BLOCKQUOTE TYPE=CITE>
    <FONT SIZE="2"><FONT COLOR="#000080">Build guys,</FONT></FONT>
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
    &nbsp;
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
    <FONT SIZE="2"><FONT COLOR="#000080">Now we have Hudson online, I have a few \
questions about Hudson:</FONT></FONT> </BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
    &nbsp;
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
    <FONT SIZE="2"><FONT COLOR="#000080">1. We still have one failure. How important \
is it to fix this? (I.e. is the failure preventing anything from happening, such as \
generation of binaries or code coverage?)</FONT></FONT><BR> </BLOCKQUOTE>
It is important if you want to have notifications and code coverage.&nbsp; \
Notifications (email) happen when you go from stable to unstable and vice-versa, so \
if the project remains unstable (aka tests are failing), then there will be no \
notifications.&nbsp; This is the typical configuration, but we can change this to \
notify on every unstable build. <BLOCKQUOTE TYPE=CITE>
    &nbsp;
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
    <FONT SIZE="2"><FONT COLOR="#000080">2. The cobertura report ( \
</FONT></FONT><FONT COLOR="#000080"><A \
HREF="http://ci.pentaho.com/job/mondrian/lastStableBuild/cobertura">http://ci.pentaho.com/job/mondrian/lastStableBuild/cobertura</A></FONT><FONT \
COLOR="#000080"><FONT SIZE="2"> ) is no longer available. What's up \
there?</FONT></FONT><BR> </BLOCKQUOTE>
Cobertura reports for some reason are only generated when there are no failing tests \
which explains why it has disappeared.<BR> <BLOCKQUOTE TYPE=CITE>
    &nbsp;
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
    <FONT SIZE="2"><FONT COLOR="#000080">3. How difficult would it be to test one or \
more other configurations? Important aspects of the configuration are JDK { jdk14, \
jdk15, jdk16 }, database { MySQL, Derby, Oracle, ... }, native evaluation { false, \
true }. One other configuration (say (jdk16, Derby, native-eval=false)) would give us \
good extra coverage.</FONT></FONT><BR> </BLOCKQUOTE>
Pretty sure that it will not be trivial to do this.&nbsp; Hudson does have a notion \
of &quot;matrix&quot; builds which allow for manipulation of axes like you mention, \
however I'm sure this will be a time-consuming effort.&nbsp; We also have the issue \
of h/w resources which will have to be bolstered greatly for this. <BLOCKQUOTE \
TYPE=CITE>  &nbsp;
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
    <FONT SIZE="2"><FONT COLOR="#000080">4. The 'megatest' shell script tests \
multiple configurations. How difficult would it be to run a shell script from hudson? \
If that's possible, megatest could be our long regress, and we could just have one \
config for the short regress. (Yeah, I used to run this on marmalade, but \
interpreting the build results was a manual process and I got behind in this \
process.)</FONT></FONT><BR> </BLOCKQUOTE>
I would recommend a separate Hudson slave to run megatest on a regular but nearly as \
frequent interval.&nbsp; How difficult?&nbsp; I personally don't know as I've never \
run them before.&nbsp; But basically anything you can do on a command line can be \
wrapped in a Hudson job, so it is very possible. <BLOCKQUOTE TYPE=CITE>
    &nbsp;
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
    <FONT SIZE="2"><FONT COLOR="#000080">5. What are your opinions about having a \
long &amp; a short regress? If so, is the ideal time for the short \
regress?</FONT></FONT><BR> </BLOCKQUOTE>
No opinion on this.&nbsp; I think the answer will be constrained by the amount of \
available CPU. <BLOCKQUOTE TYPE=CITE>
    &nbsp;
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
    <FONT SIZE="2"><FONT COLOR="#000080">By the way, there are a couple of options \
for making the short regress faster: 1. Run against Oracle-XE (it's free-as-in-beer \
and easy to install on Linux) not MySQL, 2. Don't generate code coverage.&nbsp; (I \
note that it's ~1 hr right now, whereas build+regress against Oracle takes ~7 minutes \
on marmalade.)</FONT></FONT> </BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
    &nbsp;
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
    <FONT SIZE="2"><FONT COLOR="#000080">Julian</FONT></FONT>
</BLOCKQUOTE>
</BODY>
</HTML>



_______________________________________________
Mondrian mailing list
Mondrian@pentaho.org
http://lists.pentaho.org/mailman/listinfo/mondrian


[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic