Copied in Nick, Adam and Micheal to supply the latest versions.

On Wed 11 Jul 2001 16:49, "Justin Jeffs" <[EMAIL PROTECTED]> wrote:

A lot of questions ;-)

> Thanks for replying to my email, I would like to help where I can, and some
> spare CPU time. I have a small lab at my house that is currently under
> construction,  I have a win2k box, I will have a Linux box (after I do
> rebuild), FreeBSD 3.3,  I also have VmWare that I can load almost any OS
> (Solaris, win98, etc) on if need be.  Unfortunately, I do not have any high
> end IBM, HP, or SUN hardware.

My scripts (currently) only run on unix flavours and expect a running perl
version available. Sometimes - when I'm feeling masochistic - I'm trying to
get bleadperl (the latest development state) built on Win2k, but so far I was
unsuccessful (and ActiveState's version is pretty good).

> A few questions:
> Do your scripts do auto reporting, or is something that is Ad Hoc testing?

My script is based on a cron job that does *everything* automatic. Each night
at 22:25 local time it rsyncs with the latest sources and starts building. At
09:00 it creates a report from the available test results, and mails it to
myself. I can re-create that report every once in a while, which is needed,
because most of the tests on the slow machines in my smoke bed are not done
testing at 09:00 yet.

> What is your connection to perl developers, ActiveState and CPAN?  Are you
> really in Amsterdam? If so does it matter if am in the States?

I've moved up the tree and are, hmmm, a member of the core developer team,
though not as productive as Jarkko and friends. I've got *no* relation with
ActiveState. I've got some modules on CPAN (Tk-Clock and DBD-Unify).

I live /near/ Amsterdam, and I'm a core member of Amsterdam.pm (the Amsterdam
Perl Mongers) who organize the YAPC::Europe-2.0.01 this year (2-4 Aug).

Where you live has very little influence on the test results. (It matters in
such way that if you live in the US and you sync at night, your situation
might be quite a lot more stable than when you do the same in Europe, because
when I sync at night, it's day over there, and patches are still flying around)


====== Ask if it is not clear. =============================================

Attached my current set.

l1:/pro/3gl/CPAN/perl-5.7.1 104 > crontab -l
#30 0 * * * /pro/3gl/CPAN/perl-5.6.1/smoke.sh 2>&1
45 22 * * * /pro/3gl/CPAN/perl-5.7.1/smoke.sh 2>&1
#0 8 * * * /pro/3gl/CPAN/perl-5.6.1/mkovz.pl 2>&1
0 9 * * * /pro/3gl/CPAN/perl-5.7.1/mkovz.pl 2>&1
l1:/pro/3gl/CPAN/perl-5.7.1 105 > tgz t /tmp/smoke
rw-rw-rw-   1 merijn   softwr       7852 Jul 11 17:30 /tmp/smoke.tgz
gzip -d </tmp/smoke.tgz | /pro/bin/ntar -t -v -f -
-rwxrwxrwx merijn/softwr  1493 2001-06-29 13:57:10 ../Policy.gcc
-rwxrwxrwx merijn/softwr  1324 2001-05-17 15:40:16 ../Policy.sh
-rwxr-xr-x merijn/softwr   585 2001-06-21 16:07:59 Rsync
-rwxr-xr-x merijn/softwr  1195 2001-06-12 13:48:00 Xsync
-rwxr-xr-x merijn/softwr  4806 2001-07-06 10:55:45 smoke.env
-rwxr-xr-x merijn/softwr  1010 2001-06-21 16:09:45 smoke.sh
-rwxr-xr-x merijn/softwr  6602 2001-06-22 11:34:10 mktest
-rwxr-xr-x merijn/softwr  6487 2001-06-28 13:59:19 mktest-gcc
-rwxr-xr-x merijn/softwr  5011 2001-07-06 15:32:40 mkovz.pl
-rwxr-xr-x merijn/softwr   116 2001-03-29 11:07:45 Conf
-rwxr-xr-x merijn/softwr   190 2001-07-10 15:31:06 Conf-gcc
l1:/pro/3gl/CPAN/perl-5.7.1 106 >


Here's my scene.

I've got 5 systems in a NFS cross-mounted configuration. a cron job starts
smoke.sh 5.7.1 (current blead) at night, just after the backup.

smoke.sh reads the environment from smoke.env (change this!) to reflect a
situation as would it just be my current daytime shell environment (except
that with 'at' or 'cron' the STDIN is not a tty, so -t tests would probably
fail (see sigaction.t change))

smoke.sh first rsyncs with the latest patches on the primary target machine
that has internet capabilities (and rsync installed). The rsync can be done
standalone using Rsync. Then Xsyncs the secondary targets in the NFS to the
rsynced version (Xsync is a perl script that 'pushes' the changes files over
the NFS, where rsync pulls from the source). Xsync is not perfect for this,
cause it (still) fails to remove files not anymore in the latest situation
(smoke.sh creates a shell script 'rm.sh' on the main machine that would do
what rsync --delete would have done). This might change. Change smoke.sh on
the secondary targets to not rsync if you use my Xsync approach.

After all that syncing, smoke.sh starts the (perl) script mktest and puts the
results in mktest.out (short) and mktest.log (long) and creates prepared OK and
Not OK messages in perl.ok and perl.nok that can be posted to perlbug, which I
don't.

Early in the morning (assuming all tests are done), another cron job starts
mkovz.pl to gather all mktest.out reports over the NFS and create the
mktest.rpt report, the list I post on [EMAIL PROTECTED] on a regular
basis.

Files you will have to change, if you use my approach, are smoke.env (just do
something like 'env >smoke.env' and edit it to reflect the correct at-shell
syntax (don't forget to quote complicated values). Be sure to put 'export
SMOKING=YES' in there if you want to rsync), Xsync to reflect your NFS
situation (you might instead want to start rsync on the other systems,
pulling the latest source tree from either activestate or the primary target)
and mkovz.pl to format for the systems you test. mkovz.pl now scans the
reports directly over the NFS, but if you change all the smoke.sh scripts on
the secondary target machines to rcp the report to the gathering machine, it
can fetch the data from e.g. /tmp.

Now when I come in in the morning, I just look in my mailbox to see what the
night has brought me. (All machines together will do about 340 configuration
tests if I enable all, but some machines are so slow, that theywon't complete
in 24 hours if one does not disable some tests. Drat)

Conf and Conf-gcc are short scripts that I use if anyone wants extra tests.
Imagine that the report reports ext/Time/HiRes to fail for -Duse64bitall, then
I use

        # Conf -Duse64bitall
        # cd t
        # ./perl -I ../lib ../ext/Time/Hires.t

=========

> > I am writing to find out if you have any need of Perl testers.  I am a QA
> > Engineer and would love to help with Perl 6.  Please let me know if you
> > would like any help with this process.
> 
> If you've got any CPU-cyles left, I'd be happy to send you my smoke scripts
> and a short description of how I work with them. I build more than 300 perl
> Configurations each night and send in a summary (about 1 A5 sheet) to
> perl5-porters. They'd be happy to see that extended with other hardware.
> 
> Which hardware would you be testing on?
> 
> --
> H.Merijn Brand    Amsterdam Perl Mongers (http://www.amsterdam.pm.org/)
> using perl-5.6.1, 5.7.1 & 628 on HP-UX 10.20 & 11.00, AIX 4.2, AIX 4.3,
>      WinNT 4, Win2K pro & WinCE 2.11 often with Tk800.022 &/| DBD-Unify
> ftp://ftp.funet.fi/pub/languages/perl/CPAN/authors/id/H/HM/HMBRAND/
> 


-- 
H.Merijn Brand    Amsterdam Perl Mongers (http://www.amsterdam.pm.org/)
using perl-5.6.1, 5.7.1 & 628 on HP-UX 10.20 & 11.00, AIX 4.2, AIX 4.3,
     WinNT 4, Win2K pro & WinCE 2.11 often with Tk800.022 &/| DBD-Unify
ftp://ftp.funet.fi/pub/languages/perl/CPAN/authors/id/H/HM/HMBRAND/

smoke.tgz

Reply via email to