subunit-dev team mailing list archive

[Jonathan Lange <jml@xxxxxxxxx>]

Hello,

I am trying to use subunit & Jenkins to make sure that testtools
doesn't break. I need to be sure that testtools works with Python 2.4,
2.5, 2.6, 2.7, 3.0, 3.1 and 3.2.

Right now, I'm running a script on Jenkins that looks like this::

  python2.4 /usr/lib/python2.4/site-packages/subunit/run.py
testtools.tests.test_suite | subunit2junitxml -o testtools-2.4.xml
  python2.5 -m subunit.run testtools.tests.test_suite |
subunit2junitxml -o testtools-2.5.xml
  python2.6 -m subunit.run testtools.tests.test_suite |
subunit2junitxml -o testtools-2.6.xml
  python2.7 -m subunit.run testtools.tests.test_suite |
subunit2junitxml -o testtools-2.7.xml
  python3 -m subunit.run testtools.tests.test_suite | subunit2junitxml
-o testtools-3.xml

However, I very frequently get a problem where testtools simply fails
to import, because I've done something silly wrt Python compatibility.
In this case, Python spits something to stderr and subunit2junitxml
doesn't get it.

I was thinking that it would be generally useful to have a subunit
tool that ran several scripts, expecting each of them to put subunit
output to stdout, but trapping & wrapping output to stderr if the
script crashed.

I'm ignoring a bunch of details here, probably important ones.

Do you think such a thing would be useful? Could it work? How would it
work? (I'm thinking a scripts.d/ approach)

cheers,
jml