[ANN] Ferret Smoke Test

Hey folks,

I’ve added a smoke test script to Ferret. It is named smoke_test.rb
and it can be found in the base of the working directory.

So what are you supposed to do with it you ask? Well, if you want to
help keep Ferret working on your system of choice then set up a cron
task to run this script regularly. What the script does is call svn update to get the latest working revision. If it is already at the
latest revision it stops there. Otherwise it will run both the
straight C unit tests and the Ferret unit tests and post the results
here:

http://camping.davebalmain.com/smoke_alarm/

And I’ll be notified if anything breaks. This way I’ll know of I’m
breaking Ferret on a different system to mine, when I make make the
next check-in.

So if you want to get on board, here is a summary:

prompt> svn co svn://www.davebalmain.com/exp ferret
prompt> cd ferret
prompt> ruby smoke_test.rb # no-op since you are already at latest
revision

Now add the script to your crontab[1] or whatever you use to

schedule

processes on your system. For me, I did this:

prompt> sudo vi /etc/crontab

then add the following line:

17 * * * * root /usr/bin/ruby /path/to/smoke_test.rb true
[email protected]

The first parameter specifies whether to do a full rebuild before
testing. This is preferable although it will take a little more
processor time. The second parameter is obviously your email address.
Don’t worry, it won’t be published anywhere. It just lets me contact
you about any problems that are showing up on your system.

A quick disclaimer to finish off. I hacked this up pretty quickly so
there are probably a few improvements that could be made. Please feel
free to post your suggestions.

Cheers,
Dave

[1] There is a brief cron tutorial here:

Clockwatchers Web Hosting - Cron Tutorial - General

Hey …

I’ve added a smoke test script to Ferret. It is named smoke_test.rb
and it can be found in the base of the working directory.

Great! You will get a x86_64-linux result once a day :slight_smile:

prompt> sudo vi /etc/crontab

then add the following line:

17 * * * * root /usr/bin/ruby /path/to/smoke_test.rb true
[email protected]

I would suggest not doing this as root … it will run fine as a standard
user … If someone hacks
your Makefile, a lot of people might be in troube :wink:

A quick disclaimer to finish off. I hacked this up pretty quickly so
there are probably a few improvements that could be made. Please feel
free to post your suggestions.

I’ll definately take a look …

Ben

On 10/18/06, Benjamin K. [email protected] wrote:

I would suggest not doing this as root … it will run fine as a standard
user … If someone hacks
your Makefile, a lot of people might be in troube :wink:

Oh, good catch Ben. That will teach me for cut and pasting. For that
same reason, beware adding it to /etc/cron.hourly ro /etc/cron.daily
as they are probably run by root too.

Dave

Hi,

I’m on Mac OS X, PPC64. Just ran the smoke_alarm script but before it
would run I had to install Ruby 1.8.4 (for Net:HTTP.post_form). So I now
have /usr/bin/ruby (1.8.2) and /usr/local/bin/ruby (1.8.4)

I started the script using /usr/local/bin/ruby (1.8.4) but it failed
with this during ruby tests:

Loading once
Loaded suite
/usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake/rake_test_loader
Started
…rake
aborted!
Command failed with status (): [/usr/bin/ruby -Ilib:test/unit
"/usr/lib/ru…]

Looks like it’s still trying to use /usr/bin/ruby (1.8.2). Is that going
to be the problem?

Pete.

Hi Pete,
I’m not aware of anyone running Ferret with Ruby 1.8.2 so I can’t say
if it will be a problem or not. By the looks of it, it is. Could you
post the full error message?

I can’t seem to reproduce it, but the results of that run did end up
getting posted as “Test run on 2006-10-18 22:38:15”. Now, even with a
PATH that favours Ruby 1.8.2, the tests all seem to pass when I call
make and rake on the command line and when I run smoke_alarm.rb manually
or from cron (commenting out the no-op and form submission code). Not
sure what was going on but it seems to have gone away.

1.8.2 is the version that comes stock with Mac OS X which is why I’ve
been using it so there might be others in the same boat. I’m now testing
against 1.8.4, but if you’d like someone to be testing against 1.8.2 I
could do that. There appears to be someone else testing against
ppc64/1.8.4 anyway. What do you think?

Pete.

On 10/19/06, Peter R. [email protected] wrote:

sure what was going on but it seems to have gone away.
Great :D. One less thing for me to worry about.

1.8.2 is the version that comes stock with Mac OS X which is why I’ve
been using it so there might be others in the same boat. I’m now testing
against 1.8.4, but if you’d like someone to be testing against 1.8.2 I
could do that. There appears to be someone else testing against
ppc64/1.8.4 anyway. What do you think?

Pete.

It’d be nice to have someone testing against 1.8.2 but I wouldn’t want
you to have to use 1.8.2 just to run Ferret’s smoke test. I’ll leave
it up to you.

Cheers,
Dave

On 10/18/06, Peter R. [email protected] wrote:

Loaded suite
Pete.
Hi Pete,
I’m not aware of anyone running Ferret with Ruby 1.8.2 so I can’t say
if it will be a problem or not. By the looks of it, it is. Could you
post the full error message?

By the way, the reason that it reverts to /usr/lib/ruby is that the
script makes a system call to rake which automatically uses the old
version of ruby, probably because it appears first in the execution
path.

Cheers,
Dave

On 10/23/06, Peter R. [email protected] wrote:

@version_info = io.read
end

…to get the version being used to run the tests, so it’ll just a
matter of parsing it to extract the different pieces of info.

I like this solution. I’m not really concerned about parsing it to
extract the different fields. It is just to give me an indication of
the system the test is running on so leaving it in a single field
should be fine.

Cheers,
Dave

OK I’ll go with 1.8.2 then. I’ve got both 18.2 and 1.8.4 installed so
it’s not a drama.

The only thing is that smoke_alarm.rb reports the version it’s being run
against (has to be 1.8.4), not necessarily the one being used to run the
tests. I might have a crack at fixing this up a bit later and maybe send
you a patch. I’ve done one trial run (“Test run on 2006-10-23 10:03:18”)
which uses…

IO.popen(‘ruby -v’) do |io|
@version_info = io.read
end

…to get the version being used to run the tests, so it’ll just a
matter of parsing it to extract the different pieces of info.

Pete.

David B. wrote:

I’m not really concerned about parsing it

It was simple enough so I parsed it anyway. Keeps it in sync with the
existing CGI I figured.

http://ferret.davebalmain.com/trac/ticket/145

Pete.