
The clusterpush.pl script allows you to run a cluster regression using
code that has not been committed to git. 

Usage:

  clusterpush.pl [product] ['bmpcmp'] ['lowres'|'hires'] ['relaxtimeout'] ['filter='] ['extras='] [user]


Where product is one or more of gs, pcl, and xps or mupdf or mujstest.
If you do not specify a product the product(s) tested will be based on
what directory you are 'cd'ed to when the clusterpush.pl script is run.

bmpcmp indicates that a bitmap comparison of your output to that of the
last svn commit should be performed.

lowres or hires indicates to only perform a low-resolution or
high-resolution cluster run; by default both are performed.

relaxtimeout relaxes the timeout for each job, from 5 minutes to
30 minutes.  Note that the total time for the cluster job is still
limited to 2 hours.

filter= limits jobs to those matching the specified parameter, for
example filter=pgmraw will only test pgmraw files.

This option can be specified multiple times, in which case the filters
are or'd together; i.e. filter=pgmraw filter=ppmraw will process both
pgmraw and ppmraw files.

Separating multiple paramters seperated by a comma ands the filters
together; i.e. filter=300,pbmraw processed only 300 dpi pbmraw files.

extras= add extra command line options to a cluster job,
i.e. extras=-dEPSCROP.

This option can be specified multiple times.

user is your cluster user name, if you don't specify one, clusterpush.pl
uses, in order of preference, the value of one of the following
environment variables: CLUSTER_USER, USER, and USERNAME This works under
Linux, Mac OS X, Msys, and probably cygwin.

The order of the options is not important.

You need to run clusterpush.pl from the top level directory (the same
directory from where you normally run 'make').  Clusterpush prints an
error if you try to run it from a different directory.

Results will be sent via email after the run is completed, which takes
about 10 minutes, presuming the cluster isn't busy.  Your code is compared
to the most recent baseline, so for meaningful results you will want
to sync your code with head if recent changes to head have resulted in
regression differences.

The first time you run clusterpush.pl it will take a really long time
to rsync your source to the master machine and then from the master to
the nodes.  After that things will go much quicker (unless, like me,
you accidently leave giant .ppm files in the current directory).

bmpcmp mode:

To use the feature run clusterpush.pl with the option bmpcmp (i.e.
"toolbin/localcluster/clusterpush.pl bmpcmp").  This will queue a job
that looks at the most recent none-bmpcmp clusterpush job you ran and
generates bitmaps of the differences for the first 1000 files listed
in the report.  It puts these files on the internets in the location
<http://www.ghostscript.com/~regression/$USER> and then sends you
an email telling you that it's done.  Since some of the test files
are customer confidential this directory is password protected, I've
emailed out passwords, contact me if you have misplaced your password.
BTW, I consider the fact that can look at output from other users, e.g.
<http://www.ghostscript.com/~regression/marcos>, a feature since this
allows users to refer to bmpcmp output in email and IRC disucssions
without having to email files around.

You can add bmpcmp to a normal clusterpush (i.e. 'clusterpush gs bmpcmp'
or 'clusterpush gs pcl xps bmpcmp').  This will queueu both jobs in
the correct sequence.

abort mode:

If you want to abort a queued or currently running cluster job you can
specify abort to the clusterpush.pl option: 'clusterpush.pl abort'.


