I agree that this is something that would be pretty straightforward to script. Depending on how your binaries are configured and how different your programs are from one another, you could even include the testing scripts as part of your SVN repository.
Since you're in a batch system, you have some freedom for scheduling the tests. You may want to have a generic "verify" job that you can provide setup parameters to (e.g. to locations of expected and actual program output output). Nick mentioned using grep
to check the output of qstat
for your job ID, but you can tell PBS to hold a job until another job completes. This would mean that you have something like:
...
#PBS -N run_test_1
#PBS -a 200906270000
...
<compile test>
<run test>
<save output>
when submitted, save the job ID returned by qsub
(how you do this is dependent on your platform - usually something like job_id=$(qsub $JOB_FILE)
is sufficient). Then, plug that value in to another script:
...
#PBS -N verify_test_1
#PBS -W depend=afterany:$job_id
<run comparison>
...
This will (when the proper value of job_id
is inserted) hold the execution of the test run until midnight on June 27, 2009, and hold the execution of the verification job until the test job completes (the afterany
directive indicates that it should always run after the first job - not just if it's successful).
Depending on your cluster's turnaround time, though, you could put all of this in one script, though you could still use the PBS time-based holds to only run at a particular time. I've recently started using Python instead of shell scripts to handle even this system-related jobs - I tested yesterday making the Python script executable and adding the PBS directives straight into the source - it seemed to work very well.