Received: by 10.150.191.10 with SMTP id o10mr3404126ybf.9.1244248146260;
Fri, 05 Jun 2009 17:29:06 -0700 (PDT)
Return-Path: <marc.es...@gmail.com>
Received: from mail-gx0-f229.google.com (mail-gx0-f229.google.com [209.85.217.229])
by gmr-mx.google.com with ESMTP id 16si143287gxk.1.2009.06.05.17.29.06;
Fri, 05 Jun 2009 17:29:06 -0700 (PDT)
Received-SPF: pass (google.com: domain of marc.es...@gmail.com designates 209.85.217.229 as permitted sender) client-ip=209.85.217.229;
Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of marc.es...@gmail.com designates 209.85.217.229 as permitted sender) smtp.mail=marc.es...@gmail.com
Received: by gxk13 with SMTP id 13so4018687gxk.11
for <mxunit@googlegroups.com>; Fri, 05 Jun 2009 17:29:06 -0700 (PDT)
Mime-Version: 1.0
Content-Type: multipart/alternative;
boundary="0016361e7d94c31d73046ba3185f"
In-Reply-To: <afe663af0906051534h3deb2948o43ad81adb37aa3ef@mail.gmail.com>
Received: by 10.90.92.16 with SMTP id p16mr3649322agb.7.1244248146120; Fri, 05
Jun 2009 17:29:06 -0700 (PDT)
Message-ID: <0016361e7d94c31d84046ba31862@google.com>
Date: Sat, 06 Jun 2009 00:29:06 +0000
Subject: Re: Re: [mxunit:1294] Re: Unit Profiling?
From: marc.es...@gmail.com
To: mxunit@googlegroups.com
--0016361e7d94c31d73046ba3185f
Content-Type: text/plain; charset=ISO-8859-1
Hey Randy,
I updated the blog post here
http://blog.mxunit.org/2009/06/continuous-integration-with-hudson-cf.html
to show what the time trend graph looks like. I suspect that once you get
it set up and running steady, the graph will even out and then be more
meaningful as a tool because if things are going wrong, it'll creep up.
marc
On Jun 5, 2009 6:34pm, Marc Esher <marc.es...@gmail.com> wrote:
> here's my quickie answer on hudson then i gotta split for a while:
> hudson has extremely low overhead. You could literally install tomcat
> on a box, drop hudson into it, schedule tests, and the only blip you'd
> get would be whenever it ran your tests. I have it running on my
> laptop all the time and I never notice it. At work, I'm about to
> install it on one of our old "we're gonna pitch this box if noone
> wants to use it" machines and I'm fully confident that it'll be fine.
> in my case -- and it sounds like yours -- it's definitely not this
> monolithic monster thing that's fetching sources from a thousand
> different subversion repositories around the globe, compiling for an
> hour, and running millions of tests. Rather, it's just an app that's
> gonna make http calls to your tests and record the results. You could
> probably run it on your desktop, and firefox will take up more memory
> than hudson would most of the time.
> Definitely don't be afraid of it in terms of server-hoggishness. It's no
> pig.
> On Fri, Jun 5, 2009 at 6:20 PM, RandyZoram...@gmail.com> wrote:
> >
> > Very good questions and points.
> >
> > To start, I'll describe the position that I am in. Right now I am
> > starting work on a new project and trying to start off on the right
> > foot and get all the automation and build processes setup from the get-
> > go. As far as a team goes, I am working with a few people on the
> > project but most of the time it will be me doing most of the
> > programming. I would really like to have a CI server setup, atm I
> > don't know if that is going to be financially feasible to have running
> > all the time, can you setup hudson locally or be setup on an EC2
> > instance and just started and stopped when I want to use it? I don't
> > know how well hudson would do with being started and stopped.
> >
> > I would be interested in the general unit testing times to look for
> > trends, but for some of the core code it would be nice to see it when
> > functions are run thousands of times, but I don't really know if that
> > would be worth the effort, or if I should just rely on the overall
> > tests.
> >
> > So, really I would like to have a CI server for when things get
> > larger, then it will just be part of the process, and not have to be
> > rigged later on to a larger project.
> >
> > Randy
> >
> > On Jun 5, 4:50 pm, Marc Esher marc.es...@gmail.com> wrote:
> >> Randy,
> >> Do you want to see the global view of trending for all your tests
> >> over time? you can easily get that from the main hudson screen. Though
> >> I see now that I didn't put any screenshots up about that. I have a
> >> post in the works -- probably the one i should've started with -- on
> >> "why the hell would you even need this stuff?", which will cover my
> >> own motivation for investigating hudson, and in fact it started with
> >> time trending!
> >>
> >> but i'm not so much concerned about 'does test 1 take longer today
> >> than it took yesterday'. I'm concerned about "are all my tests
> >> progressively taking longer to run", which would indicate some
> >> problem. then i could presumably drill down into the tests to get at
> >> that information. yes, you get the total time tests take when you dig
> >> into the test results.
> >>
> >> i'm not sure what other stuff is out there yet for getting
> >> more/better/easier-to-read information with respect to time trending
> >> in Hudson, but I'll definitely be digging into that b/c it's important
> >> to me. I do know that continuous integration servers generally have a
> >> mechanism for causing builds to fail when build times spike, but i
> >> haven't implemented that in hudson yet so I don't know how it's done.
> >>
> >> I'm curious: are you working alone, or on a team? I think for me,
> >> this would influence whether I went down the CI route or whether I
> >> just rolled my own test result app.
> >>
> >> marc
> >
> >
> >
--0016361e7d94c31d73046ba3185f
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Hey Randy,<br /><br />I updated the blog post here http://blog.mxunit.org/2=
009/06/continuous-integration-with-hudson-cf.html to show what the time tre=
nd graph looks like. I suspect that once you get it set up and running stea=
dy, the graph will even out and then be more meaningful as a tool because i=
f things are going wrong, it'll creep up.<br /><br />marc<br /><br />On=
Jun 5, 2009 6:34pm, Marc Esher <marc.es...@gmail.com> wrote:<br />&g=
t; here's my quickie answer on hudson then i gotta split for a while:<b=
r />> <br />> hudson has extremely low overhead. You could literally =
install tomcat<br />> <br />> on a box, drop hudson into it, schedule=
tests, and the only blip you'd<br />> <br />> get would be whene=
ver it ran your =A0tests. I have it running on my<br />> <br />> lapt=
op all the time and I never notice it. =A0At work, I'm about to<br />&g=
t; <br />> install it on one of our old "we're gonna pitch this=
box if noone<br />> <br />> wants to use it" machines and I'=
;m fully confident that it'll be fine.<br />> <br />> <br />> =
<br />> in my case -- and it sounds like yours -- it's definitely no=
t this<br />> <br />> monolithic monster thing that's fetching so=
urces from a thousand<br />> <br />> different subversion repositorie=
s around the globe, compiling for an<br />> <br />> hour, and running=
millions of tests. Rather, it's just an app that's<br />> <br /=
>> gonna make http calls to your tests and record the results. =A0You co=
uld<br />> <br />> probably run it on your desktop, and firefox will =
take up more memory<br />> <br />> than hudson would most of the time=
.<br />> <br />> <br />> <br />> Definitely don't be afraid=
of it in terms of server-hoggishness. It's no pig.<br />> <br />>=
; <br />> <br />> On Fri, Jun 5, 2009 at 6:20 PM, RandyZoramite@gmail=
.com> wrote:<br />> <br />> ><br />> <br />> > Very go=
od questions and points.<br />> <br />> ><br />> <br />> >=
; To start, I'll describe the position that I am in. Right now I am<br =
/>> <br />> > starting work on a new project and trying to start o=
ff on the right<br />> <br />> > foot and get all the automation a=
nd build processes setup from the get-<br />> <br />> > go. As far=
as a team goes, I am working with a few people on the<br />> <br />>=
> project but most of the time it will be me doing most of the<br />>=
; <br />> > programming. I would really like to have a CI server setu=
p, atm I<br />> <br />> > don't know if that is going to be fi=
nancially feasible to have running<br />> <br />> > all the time, =
can you setup hudson locally or be setup on an EC2<br />> <br />> >=
; instance and just started and stopped when I want to use it? I don't<=
br />> <br />> > know how well hudson would do with being started =
and stopped.<br />> <br />> ><br />> <br />> > I would be=
interested in the general unit testing times to look for<br />> <br />&=
gt; > trends, but for some of the core code it would be nice to see it w=
hen<br />> <br />> > functions are run thousands of times, but I d=
on't really know if that<br />> <br />> > would be worth the e=
ffort, or if I should just rely on the overall<br />> <br />> > te=
sts.<br />> <br />> ><br />> <br />> > So, really I would=
like to have a CI server for when things get<br />> <br />> > lar=
ger, then it will just be part of the process, and not have to be<br />>=
<br />> > rigged later on to a larger project.<br />> <br />> =
><br />> <br />> > Randy<br />> <br />> ><br />> <b=
r />> > On Jun 5, 4:50=A0pm, Marc Esher marc.es...@gmail.com> wrot=
e:<br />> <br />> >> Randy,<br />> <br />> >> =A0 D=
o you want to see the global view of trending for all your tests<br />> =
<br />> >> over time? you can easily get that from the main hudson=
screen. Though<br />> <br />> >> I see now that I didn't p=
ut any screenshots up about that. I have a<br />> <br />> >> po=
st in the works -- probably the one i should've started with -- on<br /=
>> <br />> >> "why the hell would you even need this stuff=
?", which will cover my<br />> <br />> >> own motivation f=
or investigating hudson, and in fact it started with<br />> <br />> &=
gt;> time trending!<br />> <br />> >><br />> <br />> &=
gt;> =A0 but i'm not so much concerned about 'does test 1 take l=
onger today<br />> <br />> >> than it took yesterday'. I=
9;m concerned about "are all my tests<br />> <br />> >> pr=
ogressively taking longer to run", which would indicate some<br />>=
<br />> >> problem. then i could presumably drill down into the t=
ests to get at<br />> <br />> >> that information. yes, you get=
the total time tests take when you dig<br />> <br />> >> into =
the test results.<br />> <br />> >><br />> <br />> >&g=
t; =A0 i'm not sure what other stuff is out there yet for getting<br />=
> <br />> >> more/better/easier-to-read information with respec=
t to time trending<br />> <br />> >> in Hudson, but I'll de=
finitely be digging into that b/c it's important<br />> <br />> &=
gt;> to me. I do know that continuous integration servers generally have=
a<br />> <br />> >> mechanism for causing builds to fail when =
build times spike, but i<br />> <br />> >> haven't implemen=
ted that in hudson yet so I don't know how it's done.<br />> <br=
/>> >><br />> <br />> >> I'm curious: are you wor=
king alone, or on a team? =A0I think for me,<br />> <br />> >> =
this would influence whether I went down the CI route or whether I<br />>=
; <br />> >> just rolled my own test result app.<br />> <br />&=
gt; >><br />> <br />> >> marc<br />> <br />> > <=
br />> <br />> ><br />> <br />> ><br />>
--0016361e7d94c31d73046ba3185f--
Message from discussion Unit Profiling?
| Create a group - Google Groups - Google Home - Terms of Service - Privacy Policy |
| ©2013 Google |