[sf-perl] [meeting] Hudson and Perl - why?

Paul Makepeace Paul.Makepeace at realprogrammers.com
Thu Jun 10 17:53:48 PDT 2010


One approach is to split your test suite into say 'small', 'medium',
'large' and define your smoke tests as say small only or small &
medium, or some other slice that covers you in the 80/20 sense.
Essentially you're looking to run a set of tests that doesn't take too
long but covers a good chunk of the 'obviously broken' scenarios.



On Thu, Jun 10, 2010 at 16:37, Michael Friedman
<friedman at highwire.stanford.edu> wrote:
> And when you have a 808,303 line perl project, even running the tests on one platform takes over two hours. So, except in rare circumstances, you don't want developers to have to run the full test suite; you want a machine to do it for you and email you the results.
>
> I'm running the tests manually now, and because it takes so long, I don't run them nearly as often as I should...
>
> Needless to say, I'm really looking forward to this presentation.
> -- Mike
> ______________________________________________________________________________
> Mike Friedman | HighWire Press, Stanford Univ | friedman at highwire.stanford.edu
>
> On Jun 10, 2010, at 3:59 PM, David Muir Sharnoff wrote:
>
>> Sometimes running the tests takes real effort.    In my case, I want to run
>> three versions of the software on eight OS platforms and each of those
>> runs takes
>> more than half an hour.   Having a CI system handle it has benefits.
>>
>> -Dave
>>
>> On Thu, Jun 10, 2010 at 3:48 PM, James Briggs <james at actionmessage.com> wrote:
>>> On Thu, 10 Jun 2010 13:08:54 -0700, Fred Moyer wrote
>>>> Joe McMahon will be talking about Hudson on June 22nd at 7pm, at the
>>>> office of Mother Jones (located on Sutter street, please login to
>>>> Meetup for the exact address).
>>>>
>>>> "Continuous integration" sounds like a great idea: you automatically
>>>> run your build on every checkin, so you know very soon after you've
>>>> committed if you make a mistake or checked in a bug. However, like
>>>> any properly lazy Perl programmer, the last thing you want to do is write
>>>> more code; you want to take advantage of work that's already done:
>>>> that's Hudson.
>>>
>>> Hi folks.
>>>
>>> I've worked as a build and release engineer on compiler projects with CI
>>> tools like Buildbot. There was a clear benefit from continuous builds
>>> with multiple programmers modifying a large C code base.
>>>
>>> But since scripting languages don't have a compile or link stage, I'm a
>>> little puzzled at the utility of Hudson with Perl projects.
>>>
>>> I guess you could have Hudson run perl -c on each source file, and run
>>> the tests.
>>>
>>> (I just use a batch file for that on a 100,000 line Perl project.)
>>>
>>> Anybody care to share some examples of using a CI tool with Perl where
>>> there was a benefit to developers?
>>>
>>> Thanks,
>>> James
>>> _______________________________________________
>>> SanFrancisco-pm mailing list
>>> SanFrancisco-pm at pm.org
>>> http://mail.pm.org/mailman/listinfo/sanfrancisco-pm
>>>
>>>
>> _______________________________________________
>> SanFrancisco-pm mailing list
>> SanFrancisco-pm at pm.org
>> http://mail.pm.org/mailman/listinfo/sanfrancisco-pm
>
> _______________________________________________
> SanFrancisco-pm mailing list
> SanFrancisco-pm at pm.org
> http://mail.pm.org/mailman/listinfo/sanfrancisco-pm
>


More information about the SanFrancisco-pm mailing list