- Zope-Dev - Zope lists

Automating tests of the ZTK / zopeapp package sets
by Tres Seaver 07 Mar '10

07 Mar '10

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 After successfully configuring the Hudson[1] continuous integration server yesterday to test the various repoze.* packages[2], I thought I would experiment with using it to drive the compatibility tests for ZTK and zopeapp. Here is what I did: In a shell on my server: $ wget http://hudson-ci.org/latest/hudson.war $ java -jar hudson.war --httpPort=19999 .... In the browser, visit 'http://laguna.palladion.com:19999, and configure the server: - - Enable security - allow signup - using Matrix - set up 'tseaver' as having all permissions - set up 'anonymous' as having 'Read' permission overall and for jobs - - Register as 'tseaver' - Turn off signup (no, I don't want you guys running arbitrary shell scripts on my server ;). - - Create a job, 'ztk-trunk-py26': http://laguna.palladion.com:19999/job/ztk-trunk-py26/ - Use SVN, pointed at 'svn://svn.zope.org/repos/main/zopetoolkit/trunk' - Set to poll SVN every 15 minutes. - Enable using 'svn up' - Added build step as a shell script:: cd trunk /opt/Python-2.6.4/bin/python bootstrap.py bin/buildout bin/test-ztk bin/test-zopeapp - Ran a build manually. The first one barfed due to a typo in my script, but the second one ran, taking 21 minutes. The test runs successfully to completion, but doesn't produce statistics in a form that Hudson understands. The following changes to 'zope.testing.testrunner' would make the output more informative: - Add a flag like the '--with-xunit' flag to the Nose testrunner, which dumped results into a JUnit-compatible XML file[3]. - Add a flag like the '--with-xcompat' flag to the Nose testrunner (when run with the 'nosexcover' plugin), producing a Cobertura- compabtible XML file[4]. At that point, the build process would be nicely automated, with browsable results including coverage, pretty graphs, etc. See the 'repoze' jobs for examples of those outputs. Questions for discussion: - - I find the prettier interface and easier setup than buildbot worth running a 3rd-party Java app (rather than a 3rd party Python app). Would that be acceptable among the folks running our automated tests? - - Is it worth adding the XML support for test results and coverage to 'zope.testing.testrunner'? - - Would people be willing to run Hudson "permanently" on enough hosts to make this a reasonable replacement for buildbot (we need Windows, too)? - - Hudson seems general purpose enough to allow automating other code- related tasks, e.g., production of dependency graphs. Maybe we could even automate building Windows installers? I will try to leave the ZTK Hudson server up for a little bit, to allow folks to see what it can deliver already. [1] http://hudson-ci.org/ [2] http://hudson.repoze.org/ [3] http://old.nabble.com/schema-for-junit-xml-output-td22193385.html [4] http://cobertura.sourceforge.net/xml/coverage-01.dtd Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver(a)palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkuQIcAACgkQ+gerLs4ltQ61pACfXsIdiRGY2LQ+u8d/qpG2okpT eKQAn0gjegHqlvu7w3RV01IruUx7S5QM =OmZN -----END PGP SIGNATURE-----

7 7

Zope Tests: 6 OK
by Zope Tests Summarizer 07 Mar '10

07 Mar '10

Summary of messages to the zope-tests list. Period Sat Mar 6 12:00:00 2010 UTC to Sun Mar 7 12:00:00 2010 UTC. There were 6 messages: 6 from Zope Tests. Tests passed OK --------------- Subject: OK : Zope-2.10 Python-2.4.6 : Linux From: Zope Tests Date: Sat Mar 6 20:45:12 EST 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-March/013690.html Subject: OK : Zope-2.11 Python-2.4.6 : Linux From: Zope Tests Date: Sat Mar 6 20:47:12 EST 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-March/013691.html Subject: OK : Zope-2.12 Python-2.6.4 : Linux From: Zope Tests Date: Sat Mar 6 20:49:12 EST 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-March/013692.html Subject: OK : Zope-2.12-alltests Python-2.6.4 : Linux From: Zope Tests Date: Sat Mar 6 20:51:12 EST 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-March/013693.html Subject: OK : Zope-trunk Python-2.6.4 : Linux From: Zope Tests Date: Sat Mar 6 20:53:12 EST 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-March/013694.html Subject: OK : Zope-trunk-alltests Python-2.6.4 : Linux From: Zope Tests Date: Sat Mar 6 20:55:12 EST 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-March/013695.html

1 0

Version bumping in the trunk after release
by Baiju M 07 Mar '10

07 Mar '10

Hi, I would propose a one word change in the "Releasing Software" document which is part of process documentation for zopetookit. After preparing a release, developer increase next version number to next feature version or next bugfix version. From the explanation given there, it is very obvious that the number should be changed to next bugfix release. I think the wording also should be changed, so that there won't be any confusion. This sentence: Back on the trunk or the release branch, increase the version number in ``setup.py`` to the *next* release while preserving the ``dev`` marker. Should be changed to: Back on the trunk or the release branch, increase the version number in ``setup.py`` to the *next* bugfix release while preserving the ``dev`` marker. If there is no objection, I am going to make this change after 3 days. To understand the context, here is the full text: 6. Back on the trunk or the release branch, increase the version number in ``setup.py`` to the *next* bugfix release while preserving the ``dev`` marker. The convention is that the trunk or release branch always points to the upcoming release, *not* the one that has been released already. So if you've just released version 3.4.1, you should change ``setup.py`` to read:: setup( name='...', version='3.4.2dev', ... ) In ``CHANGES.txt`` add a *new* section for the upcoming release. The release date for that should say "unreleased" so that committers recording their changes won't accidentally put their entry in the section for an already released version. For example:: 3.4.2 (unreleased) ------------------ * ... 3.4.1 (2007-01-24) ------------------ * Fixed bug in the foo adapter. * Added a bar utility for optimized kaboodling. 3.4.0 (2006-09-13) ------------------ Initial release as separate egg. Regards, Baiju M Index: source/process/releasing-software.rst =================================================================== --- source/process/releasing-software.rst (revision 109748) +++ source/process/releasing-software.rst (working copy) @@ -74,7 +74,7 @@ versions and linking models (framework / non-framework). 6. Back on the trunk or the release branch, increase the version - number in ``setup.py`` to the *next* release while preserving the + number in ``setup.py`` to the *next* bugfix release while preserving the ``dev`` marker. The convention is that the trunk or release branch always points to the upcoming release, *not* the one that has been released already. So if you've just released version 3.4.1, you

1 0

Re: [Zope-dev] SVN: DateTime/trunk/src/DateTime/tests/testDateTime.py add a failing test for a regression in parsing ISO format datetimes from DateTime 2.10, as discussed at http://dev.plone.org/plone/ticket/10140 ...note that this will give a false positive if run on a computer where GMT is the local timezone
by Tres Seaver 07 Mar '10

07 Mar '10

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 David Glick wrote: > Log message for revision 109667: > add a failing test for a regression in parsing ISO format datetimes from DateTime 2.10, as discussed at http://dev.plone.org/plone/ticket/10140 ...note that this will give a false positive if run on a computer where GMT is the local timezone Please don't deliberately check in failing tests on the trunk. If you need to do this, make a branch, and ask on the mailing list for people to investigate your branch. > Changed: > U DateTime/trunk/src/DateTime/tests/testDateTime.py > > -=- > Modified: DateTime/trunk/src/DateTime/tests/testDateTime.py > =================================================================== > --- DateTime/trunk/src/DateTime/tests/testDateTime.py 2010-03-05 03:41:57 UTC (rev 109666) > +++ DateTime/trunk/src/DateTime/tests/testDateTime.py 2010-03-05 07:04:12 UTC (rev 109667) > @@ -332,6 +332,7 @@ > ref2 = DateTime('2006/11/6 10:30 GMT') > ref3 = DateTime('2004/06/14 14:30:15 GMT-3') > ref4 = DateTime('2006/01/01 GMT') > + ref5 = DateTime('2006/01/01') Note that this a nonreproducible test value: parsing the string with slashes but no timezone always gives you "local time". Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver(a)palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkuRWQQACgkQ+gerLs4ltQ7fUwCg1sqO48X6vjW/pgyq+2I4OGV0 j/IAn0/IZy+/d9+O/nEykkTLBLVYxdua =paH6 -----END PGP SIGNATURE-----

2 2

Zope Tests: 7 OK
by Zope Tests Summarizer 06 Mar '10

06 Mar '10

Summary of messages to the zope-tests list. Period Fri Mar 5 12:00:00 2010 UTC to Sat Mar 6 12:00:00 2010 UTC. There were 7 messages: 1 from Christian Theune, 6 from Zope Tests. Tests passed OK --------------- Subject: OK: Something that is tested From: Christian Theune Date: Fri Mar 5 07:29:00 EST 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-March/013683.html Subject: OK : Zope-2.10 Python-2.4.6 : Linux From: Zope Tests Date: Fri Mar 5 20:36:30 EST 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-March/013684.html Subject: OK : Zope-2.11 Python-2.4.6 : Linux From: Zope Tests Date: Fri Mar 5 20:38:30 EST 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-March/013685.html Subject: OK : Zope-2.12 Python-2.6.4 : Linux From: Zope Tests Date: Fri Mar 5 20:40:30 EST 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-March/013686.html Subject: OK : Zope-2.12-alltests Python-2.6.4 : Linux From: Zope Tests Date: Fri Mar 5 20:42:30 EST 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-March/013687.html Subject: OK : Zope-trunk Python-2.6.4 : Linux From: Zope Tests Date: Fri Mar 5 20:44:30 EST 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-March/013688.html Subject: OK : Zope-trunk-alltests Python-2.6.4 : Linux From: Zope Tests Date: Fri Mar 5 20:46:30 EST 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-March/013689.html

1 0

Re: [Zope-dev] Uses of the ZTK and how it relates to management
by Fabio Tranchitella 05 Mar '10

05 Mar '10

* 2010-03-03 21:44, Jim Fulton wrote: > The ZTK was created in part to deal with instability issues arising from > people working on parts without testing the whole. I suppose everybody here agrees that any change to a package which is part of the ZTK *must* be tested against the whole ZTK. It would be easier to nd leading developers for subgroups of packages (eg. bicycle repair kit, rm generation, ...) willing to raise the quality of a specific subset of packages instead of finding a release manager willing to oversee > 60 packages, which he does not really use (because I don't think we have a single developer using *all* of the packages in the ZTK). These specific leading developers could report and synchronize with a ZTK release manager, though. My two euro cents. Fabio

6 9

Possible DateTime timezone-related regression in Zope 2.12
by Martin Aspeli 05 Mar '10

05 Mar '10

Hi, We have a failing test in plone.app.dexterity 1.0a7. This is simply trying to compare two dates: >>> from DateTime import DateTime >>> DateTime() > DateTime(md.CreationDate()) True At least here in Australia, the second test fails. Right now, the following expressions are: DateTime(): DateTime('2010/01/10 11:20:24.718203 GMT+8') md.CreationDate(): '2010-01-10 11:19:57' DateTime(md.CreationDate()): DateTime('2010/01/10 11:19:57 GMT+0') On Zope 2.10, it's a different story: DateTime(): DateTime('2010/01/10 11:34:01.508 GMT+8') md.CreationDate(): '2010-01-10 11:24:42' DateTime(md.CreationDate()): DateTime('2010/01/10 11:24:42 GMT+8') Andi Zeidler looked into it briefly, and said the following: imho, this is due a bug in `DateTime` 2.12.0. the newer version behaves differently when it's initialized via a string representation of a date — it interprets the given date to be GMT while before it was taken to be from your local time zone: $ cd ~/plone/coredev/branches $ cat foo.py from DateTime import DateTime print DateTime('2010-01-09 00:34:37') $ 3.3/bin/zopepy foo.py 2010/01/09 00:34:37 GMT+1 $ 4.0/bin/zopepy foo.py 2010/01/09 00:34:37 GMT+0 so in your test, `DateTime(md.CreationDate())` will always be the current time, but with an implicitly added 'GMT+0' while `DateTime()` will be the current time in your local time zone. so if i'm not mistaken, on plone 4.0 the test with fail for you an me (in 'GMT+x' time zones) and pass in the u.s. fun! :) Does anyone know if this change was deliberate, or what may have happened? Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book

3 3

ZTK compatibility testing
by Christian Theune 05 Mar '10

05 Mar '10

Hi, as promised I'm currently trying to write down the instructions for running ZTK tests. I need some feedback on our process. I figured there are various scenarios for which we have tools: 1. Ensure that a branch of the ZTK stays in working order For that the ZTK has test runners created by z3c.recipe.compattest which ensures that the individual tests of the ZTK packages with their respective dependencies using the specific ZTK versions are ok. This helps when evolving the versions in the ZTK. Those should be run nightly as is done by some of the buildbots. 2. Ensure that a change of a package doesn't break the set 2a: ensuring compatibility with a specific branch of the set The developer working on package X can use a compat test runner and a specific ZTK buildout configuration to run the other packages' tests combined with the development version of package X. This can/should be done by individual developers for the (newest/olders?) ZTK version they target their change for. If we can encode the "target ZTK" version for a specific package in that packages' configuration then we can also have nightly builds that perform this verification automatically. I'm not sure how to encode that, though, because the relation between the package and the ZTK is usually defined the other way around. 2b: ensuring ongoing compatibility of the trunks In addition I wonder how the various trunk versions of ZTK packages should relate to each other. Should they always build? Should we accept breakage of all trunks with each other or not? Also, there is not version of the ZTK (I think) that specifies 'use the trunk of everything', right? Christian -- Christian Theune · ct(a)gocept.com gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 0 · fax +49 345 1229889 1 Zope and Plone consulting and development

2 1

Buildbot owners: how and where to send build notifications
by Christian Theune 05 Mar '10

05 Mar '10

Hi, I took Tres' quick explanation of how the daily 'Zope tests: 6 OK' is created and put the instruction into the ZTK documentation for automated build systems: http://docs.zope.org/zopetoolkit/process/buildbots.html *I* encourage everyone who runs recurring/regular checks of any kind that ensure the quality of the code base to start sending messages there (ideally one every 24 hours). Over time we may have to improve readability, but for now I guess more is better. :) Christian -- Christian Theune · ct(a)gocept.com gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 0 · fax +49 345 1229889 1 Zope and Plone consulting and development

1 0

Zope Tests: 6 OK
by Zope Tests Summarizer 05 Mar '10

05 Mar '10

Summary of messages to the zope-tests list. Period Thu Mar 4 12:00:00 2010 UTC to Fri Mar 5 12:00:00 2010 UTC. There were 6 messages: 6 from Zope Tests. Tests passed OK --------------- Subject: OK : Zope-2.10 Python-2.4.6 : Linux From: Zope Tests Date: Thu Mar 4 20:37:17 EST 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-March/013677.html Subject: OK : Zope-2.11 Python-2.4.6 : Linux From: Zope Tests Date: Thu Mar 4 20:39:17 EST 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-March/013678.html Subject: OK : Zope-2.12 Python-2.6.4 : Linux From: Zope Tests Date: Thu Mar 4 20:41:17 EST 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-March/013679.html Subject: OK : Zope-2.12-alltests Python-2.6.4 : Linux From: Zope Tests Date: Thu Mar 4 20:43:17 EST 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-March/013680.html Subject: OK : Zope-trunk Python-2.6.4 : Linux From: Zope Tests Date: Thu Mar 4 20:45:17 EST 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-March/013681.html Subject: OK : Zope-trunk-alltests Python-2.6.4 : Linux From: Zope Tests Date: Thu Mar 4 20:47:17 EST 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-March/013682.html

1 0