Skip to content


Subversion checkout URL

You can clone with
Download ZIP
The code driving the parallel smoker
Perl Other
Branch: master
Failed to load latest commit information.
archive * moved old smoke*.yml to archive directory
cgi-bin * -min 4 is default now
etc * update
lib/CPAN/Testers * mod1 || mod2, not &&
utils mention chorny's website in generated distropref
.gitignore gitignore MYMETA
Makefile.PL * added Parse::CPAN::Packages::Fast as prereq
README * added reload index suggestion to README
SlayMakefile support file:// scheme
nosmoke_5159_2.yml * another config
smoke_5124RC2.yml * new smoke run: 5124RC2
smoke_5140RC0.yml * 2nd 5.14.0RC0 run
smoke_5140RC0_2.yml * the 2nd 5.14.0 RC0 smoke
smoke_5140RC0_3.yml * the next run
smoke_5140RC0_4.yml * config change for continued smoker run
smoke_5140RC0_5.yml * the 5th run
smoke_5140RC1_1.yml * 1st run for 5.14.0 RC1
smoke_5140RC2_1.yml * testing RC2
smoke_5140RC3_1.yml * RC3 run
smoke_5140_1.yml * the final 5.14.0 run
smoke_5141RC1.yml * smoking 5.14.1-RC1
smoke_5159.yml * 2nd smoke pass
smoke_5159linux.yml * first 5.15.9 smoking under linux
smoke_5160RC0.yml * smoke_5160RC0: testlabel is now optional, next modlist
smoke_51911.yml config for new smoke run
smoke_pre_5.14.0.yml * smoke.yml update
smoke_testsimple005.yml * preparing Test-Simple testing


Smoke the CPAN in parallel

The idea is to find regressions between e.g. two perl versions or two
versions of a basic perl module. The CPAN::Testers::ParallelSmoker
framework helps to setup such a system with small effort, i.e. writing
a small configuration file should be enough.

Documentation is not there yet, unfortunately, and initial efforts to
get the smoker running is still high. But after this step it is quite
easy to create new smokers.


Currently it's not proposed to install this distribution the usual
way. Just fetch all the prerequisites mentioned in the Makefile.PL.
Note that not all prerequisites are strictly needed for the parallel
smoker; some are just for analyzing utilities.

Make sure that is configured and the indexes are loaded (at
least call once "reload index" in the CPAN shell).

Writing the configuration file

Create a YAML file which looks like the existing smoke*.yml files in
the distribution (in the toplevel directory or "archive" directory).

The most important fields are:

* testlabel: a unique, short label which is used to create unique
  subdirectories per smoke run. Do not use exotic characters.

* perl1, perl2: If comparing two perls, then specify either the url to
  fetch the perl distribution from, or a commit id, if building a
  specific bleadperl version is needed.

* git_repository: The filesystem path to a git clone of perl's source.
  This is needed if any of perl1 or perl2 is specified by "commit".

* modlist: a list of modules to smoke. Best is to use the utility
  "utils/" for this. Note that the first run
  of this utility is usually quite slow, as many files from CPAN need
  to be fetched (a local copy could help here).

Starting the smoker

    slaymake CONFIG_FILE=smoke_something.yml

This will fetch, extract, build the perls, install the toolchain
needed for distroprefs and sending reports, and finally starting two
xterms where the modules are smoked.

The reports are stored in the directory


A comparison can be created using

    ./utils/ -config smoke_....yml

This list is usually too large. You can add to the commandline up to
four "-min" to minimize the list.

Known problems

* Interactive distributions

  Some distributions ask interactive questions while configuration.
  Usually this can be solved by creating a distropref entry
  for such distribution. Existing sample distroprefs exist here:

  Unfortunately distroprefs are usually not universally applicable,
  and often depend on a particular system configuration (OS, installed
  package set).

* Hanging tests

  There's no fix yet for this. Hanging tests are not automatically
  recognized, so you have to kill it yourself, and probably protect
  the smoker by disabling such distribution (e.g. using distroprefs).

* Tests using fixed named resources

  Some tests use e.g. a fixed port for daemons or a fixed file path
  and cause unnecessary failures.
Something went wrong with that request. Please try again.