tests revision bf5fa2c191361b0b06ab7c13cd31c0eb0a0ef824
2N/ACopyright (C) 2000 Internet Software Consortium.
2N/ASee COPYRIGHT in the source root or http://isc.org/copyright.html for terms.
2N/A
2N/A$Id: tests,v 1.12 2000/12/05 00:41:38 gson Exp $
2N/A
2N/AWe do hourly test builds of the bind9 tree. This is an attempt to
2N/Adocument how they work.
2N/A
2N/A
2N/A* How things work
2N/A
2N/AThe scripts driving the build system are in ~wpk/b9t. They are now
2N/Aunder CVS control; the repository is in rc:/proj/cvs/isc/b9t (note
2N/Athat this is a separate repository from the bind9 one). The builds
2N/Aare driven by cron jobs separately installed on each build system,
2N/Arunning as user wpk.
2N/A
2N/AThe sources are checked out, and the web reports are generated,
2N/Aon bb, as driven by the following cron jobs:
2N/A
2N/A # Check out the current bind 9 version and make the source tarball.
2N/A # Argument to maketar.sh should be v9_0 for 9.0 release branch,
2N/A # HEAD for mainline.
2N/A 35 2-22 * * * PLATFORM=BSD-3.1 && . $HOME/b9t/hosts/$PLATFORM/env && \
2N/A nice sh $HOME/b9t/bin/maketar.sh HEAD \
2N/A >/proj/build-reports/bind9/tarsrc.txt 2>&1
2N/A
2N/A #
2N/A # run the bind 9 build status report generator
2N/A #
2N/A 30 3-22 * * * perl $HOME/b9t/bin/b9status.pl \
2N/A > /proj/build-reports/bind9/bind9.html 2> /dev/null
2N/A
2N/A
2N/AEach host has a separate crontab entry for building the server and
2N/Arunning tests. Here are examples from bb and sol:
2N/A
2N/A #
2N/A # build the BSD-3.1 version of bind 9
2N/A #
2N/A 0 3-22 * * * $HOME/b9t/bin/b9t.cron BSD-3.1
2N/A
2N/A #
2N/A # bind 9 build for Solaris 5.6
2N/A #
2N/A 0 3-22 * * * $HOME/b9t/bin/b9t.cron SunOS-5.6
2N/A
2N/ADo not confuse the shell script ~wpk/b9t/bin/b9t.cron with the crontab
2N/Atemplate (?) ~wpk/b9t/b9t.cron. Although they have the same name,
2N/Athey are not related.
2N/A
2N/AThe shell script b9t.cron then calls make, using the makefile b9t.mk
2N/Ain the same location. This makefile moves the old status files out of
2N/Athe way and runs through the tests.
2N/A
2N/AThe current test schedule is as follows:
2N/A
2N/A :35 CVS tree extracted, tarball built and distributed
2N/A :00 Most tests begin
2N/A :45 Status report generator runs (was :30)
2N/A
2N/A aix: I can't seem to access that machine; it appears to be down.
2N/A bb: Build starts at top of hour, 0300 to 2200
2N/A durango: Build starts at top of hour, 0300 to 2200
2N/A trantor: Build starts at top of hour, 0300 to 2100, odd-numbered hours
2N/A only
2N/A hp: Build starts at top of hour, 0300 to 2200
2N/A irix: Build starts at top of hour, 0300 to 2200
2N/A netbsd: Build starts at top of hour, 0300 to 2200 (was :45)
2N/A aa: Build starts at top of hour, 0300 to 2200
2N/A rc: Build starts at top of hour, 0300 to 2200
2N/A mirepoix: Build starts at top of hour, 0300 to 2200
2N/A sol: Build starts at top of hour, 0300 to 2200
2N/A truffle: Build starts at top of hour, 0300 to 2200
2N/A anthrax: Build starts at top of hour, 0300 to 2200
2N/A
2N/AThe actual builds take place in a directory whose location differs
2N/Aamong systems. On most of them, it's on a local disk, under /build.
2N/AOn some, it's on NFS; in this case the location is defined in
2N/A~wpk/b9t/hosts/$PLATFORM/env.
2N/A
2N/AThe output from the make process is in
2N/A~wpk/b9t/hosts/$PLATFORM/b9t-status, and the output from
2N/AThe output from the later stages of the process is under
2N/A/proj/build-reports/bind9/hosts/$PLATFORM. To make the files
2N/Aharder to find (?), they have names starting with a period:
2N/A
2N/A .populate
2N/A .config
2N/A .build
2N/A .test
2N/A
2N/A
2N/A* Common problems
2N/A
2N/ASometime named processes fail to die when the tests are done,
2N/Ainterfering with the next test. Just kill them.
2N/A
2N/AOn hp.rc.vix.com, the tests often fail because of NFS I/O errors.
2N/AWhen this happens, the machine needs to be rebooted. It will not
2N/Acome up again without manually entering commands on the console.
2N/A
2N/AOn bb, the tests sometimes fail because .nfs* files stuck in the build
2N/Atree keep it from being completely deleted when the next test runs.
2N/AThe .nfs* files cannot be deleted, but they can be moved, so one way
2N/Aof fixing this is to move them to ~wpk.
2N/A
2N/A
2N/A* Failure locking
2N/A
2N/AWhen a test fails, further testing on that host is disabled in order
2N/Ato preserve evidence. To remove the lockout and allow more tests to
2N/Abe run, log in to bb, su, su wpk, and remove the "failed" files:
2N/A
2N/A rm /proj/build-reports/bind9/hosts/*/failed
2N/A
2N/AThe failed file itself contains an exit code, which is not particularly
2N/Auseful. The more useful information is in the various log files under
2N/Athe build report.
2N/A