Hi, it took a while, but here it is: I've put the buildout-based buildot into its own virtual machine (with enough resources hopefully). It's been running for about a week now and seems to work fairly well. I integrated the classical buildbot view and my alternative display in one installation that is accessible at: http://zopebuildout.whq.gocept.com - builds are run when the trunk of a buildout-based project is changed and at 3am CEST every day. - Updates for the project list are run before the nightly build and pick up all projects' trunks that define a buildout.cfg - Currently, all projects that don't define a test runner will appear as broken. I'll fix that soon so that non-existing test runners will be ignored. Christian -- gocept gmbh & co. kg - forsterstrasse 29 - 06112 halle (saale) - germany www.gocept.com - ct@gocept.com - phone +49 345 122 9889 7 - fax +49 345 122 9889 1 - zope and plone consulting and development
On 04.03.2008, at 09:34, Christian Theune wrote:
Hi,
it took a while, but here it is: I've put the buildout-based buildot into its own virtual machine (with enough resources hopefully).
It's been running for about a week now and seems to work fairly well. I integrated the classical buildbot view and my alternative display in one installation that is accessible at:
this host can't be resolved... wasabi:~ jodok$ dig zopebuildout.whq.gocept.com ; <<>> DiG 9.4.1-P1 <<>> zopebuildout.whq.gocept.com ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 32303 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;zopebuildout.whq.gocept.com. IN A ;; AUTHORITY SECTION: whq.gocept.com. 2 IN SOA ns2.gocept.com. domain.gocept.com. 2008021055 10800 900 604800 86400 ;; Query time: 75 msec ;; SERVER: 192.168.34.254#53(192.168.34.254) ;; WHEN: Tue Mar 4 10:10:18 2008 ;; MSG SIZE rcvd: 92
- builds are run when the trunk of a buildout-based project is changed and at 3am CEST every day.
- Updates for the project list are run before the nightly build and pick up all projects' trunks that define a buildout.cfg
- Currently, all projects that don't define a test runner will appear as broken. I'll fix that soon so that non-existing test runners will be ignored.
Christian
-- gocept gmbh & co. kg - forsterstrasse 29 - 06112 halle (saale) - germany www.gocept.com - ct@gocept.com - phone +49 345 122 9889 7 - fax +49 345 122 9889 1 - zope and plone consulting and development _______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
-- "Beautiful is better than ugly." -- The Zen of Python, by Tim Peters Jodok Batlogg, Lovely Systems GmbH Schmelzhütterstraße 26a, 6850 Dornbirn, Austria mobile: +43 676 5683591, phone: +43 5572 908060
Jodok Batlogg schrieb:
On 04.03.2008, at 09:34, Christian Theune wrote:
Hi,
it took a while, but here it is: I've put the buildout-based buildot into its own virtual machine (with enough resources hopefully).
It's been running for about a week now and seems to work fairly well. I integrated the classical buildbot view and my alternative display in one installation that is accessible at:
this host can't be resolved...
Gnah. zopebuildbot.whq.gocept.com Working with buildout and buildbot at the same time makes my brain hurt. ;) -- gocept gmbh & co. kg - forsterstrasse 29 - 06112 halle (saale) - germany www.gocept.com - ct@gocept.com - phone +49 345 122 9889 7 - fax +49 345 122 9889 1 - zope and plone consulting and development
On Tue, Mar 04, 2008 at 10:15:49AM +0100, Christian Theune wrote:
Jodok Batlogg schrieb:
On 04.03.2008, at 09:34, Christian Theune wrote:
Hi,
it took a while, but here it is: I've put the buildout-based buildot into its own virtual machine (with enough resources hopefully).
It's been running for about a week now and seems to work fairly well. I integrated the classical buildbot view and my alternative display in one installation that is accessible at:
Gnah. zopebuildbot.whq.gocept.com
Working with buildout and buildbot at the same time makes my brain hurt. ;)
Yummy. Your email prompted me to fix some of the red test failures: z3checkins (that no one cares about) and zope.component (which is actually caused by a missing dependency in zope.security). The missing zope.security dependency causes a few other package tests to fail; it would be nice if whoever knows how to make releases would release zope.security 3.4.1 with the fix. Regarding the interface itself: the default waterfall view is pretty much useless for this large number of interfaces. I like the cruise-control and latest-build views, although I'd be happier if they had more direct links to the actual test runner output. Also, I think that lack of a bin/test for any package can be rightly considered to be a bug. Marius Gedminas -- (Pdb) operationerr.w_value.w_value.w_value.w_value.w_value.w_value <pypy.interpreter.executioncontext.OperationError instance at 0x5eee30> -- one of the clearer PyPy debugging sessions (seen in Michael Hudson's sig)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Marius Gedminas wrote:
Also, I think that lack of a bin/test for any package can be rightly considered to be a bug.
'bin/test' doesn't make much sense to me as a way to run the tests belonging to the packge-being-tested: it corresopnds to the tests for an entire configured environment. I would think that getting 'python setup.py test' to work for each package-being-tested, which a) makes sure that the package works even for non-buildout-aware users, and b) fits what everybody else in the Python eggs word expects. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHzcch+gerLs4ltQ4RAr/6AJsFjJv3e45sSYytwoCAzllJxADiFwCdEJDZ S+rY9Z0cvPU1k6uCQv++qm0= =kVer -----END PGP SIGNATURE-----
On Tue, Mar 04, 2008 at 05:03:13PM -0500, Tres Seaver wrote:
Marius Gedminas wrote:
Also, I think that lack of a bin/test for any package can be rightly considered to be a bug.
'bin/test' doesn't make much sense to me as a way to run the tests belonging to the packge-being-tested: it corresopnds to the tests for an entire configured environment.
And that's what you get when you run bin/buildbot in a checkout of any zope.foo package -- an entire configured environment, sufficient for testing that package. IMHO.
I would think that getting 'python setup.py test' to work for each package-being-tested, which a) makes sure that the package works even for non-buildout-aware users, and b) fits what everybody else in the Python eggs word expects.
That would be great. Do you know how to make setup.py test invoke the zope.testing test runner? The standard unittest test runner that setuptools uses by default is not sufficient -- it doesn't know anything about test layers. Marius Gedminas -- As an aside, UPnP's implementation (which features SOAP, HTTP over multicast/broadcast UDP, and extremely odd XML) is a must-read for fans of unnatural and baroque network protocols. -- Anthony Baxter
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Marius Gedminas wrote:
On Tue, Mar 04, 2008 at 05:03:13PM -0500, Tres Seaver wrote:
Marius Gedminas wrote:
Also, I think that lack of a bin/test for any package can be rightly considered to be a bug. 'bin/test' doesn't make much sense to me as a way to run the tests belonging to the packge-being-tested: it corresopnds to the tests for an entire configured environment.
And that's what you get when you run bin/buildbot in a checkout of any zope.foo package -- an entire configured environment, sufficient for testing that package. IMHO.
I would think that getting 'python setup.py test' to work for each package-being-tested, which a) makes sure that the package works even for non-buildout-aware users, and b) fits what everybody else in the Python eggs word expects.
That would be great. Do you know how to make setup.py test invoke the zope.testing test runner? The standard unittest test runner that setuptools uses by default is not sufficient -- it doesn't know anything about test layers.
Chris McDonough added support for 'setup.py test' to the ZODB trunk: http://svn.zope.org/ZODB/trunk/setup.py?rev=84132&view=markup The set of tests which get run seems not to respect the '--all' flag, even when I hack the 'alltests()' function to force it into the testrunner optoins. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHzxhR+gerLs4ltQ4RAkjhAJ0XrmywVfUaqMORozZgl6CabD1hNQCfYXpc XUd2NI5D5qwgWf+EyRoG9rs= =9Ha8 -----END PGP SIGNATURE-----
On Wed, Mar 05, 2008 at 05:01:53PM -0500, Tres Seaver wrote:
Marius Gedminas wrote:
On Tue, Mar 04, 2008 at 05:03:13PM -0500, Tres Seaver wrote:
I would think that getting 'python setup.py test' to work for each package-being-tested, which a) makes sure that the package works even for non-buildout-aware users, and b) fits what everybody else in the Python eggs word expects.
That would be great. Do you know how to make setup.py test invoke the zope.testing test runner? The standard unittest test runner that setuptools uses by default is not sufficient -- it doesn't know anything about test layers.
Chris McDonough added support for 'setup.py test' to the ZODB trunk:
http://svn.zope.org/ZODB/trunk/setup.py?rev=84132&view=markup
The set of tests which get run seems not to respect the '--all' flag, even when I hack the 'alltests()' function to force it into the testrunner optoins.
That code finds the right test suites, but then hands it back to setuptools which runs them using the standard unittest.TextTestRunner. This won't work with any package that tries to use the zope.testrunner layer machinery to, e.g., load the zcml for functional tests. Marius Gedminas -- As easy as 3.14159265358979323846264338327950288419716
Tres Seaver wrote:
I would think that getting 'python setup.py test' to work for each package-being-tested, which a) makes sure that the package works even for non-buildout-aware users, and b) fits what everybody else in the Python eggs word expects.
+1 Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
On Tue, Mar 04, 2008 at 07:22:49PM +0200, Marius Gedminas wrote:
On Tue, Mar 04, 2008 at 10:15:49AM +0100, Christian Theune wrote:
Gnah. zopebuildbot.whq.gocept.com
Yummy. Your email prompted me to fix some of the red test failures: z3checkins (that no one cares about) and zope.component (which is actually caused by a missing dependency in zope.security).
The missing zope.security dependency causes a few other package tests to fail; it would be nice if whoever knows how to make releases would release zope.security 3.4.1 with the fix.
Meh. Apparently the zope.thread import was unnecessary and had already been fixed in trunk (by Baiju) since the zope.security 3.4.0 release. What's the right workflow when you have a buildout instance of zope.foo that exposes a problem in a zope.bar egg that may or may not be fixed in zope.bar svn trunk? Marius Gedminas -- The IQ of the group is the lowest IQ of a member of the group divided by the number of people in the group.
Hi Christian. How difficult was this to get running. I am considering a a local buildbot for my own code. The structure of my repository emulates the structure of svn.zope.org. Many thanks. Regards, David Christian Theune wrote:
Hi,
it took a while, but here it is: I've put the buildout-based buildot into its own virtual machine (with enough resources hopefully).
It's been running for about a week now and seems to work fairly well. I integrated the classical buildbot view and my alternative display in one installation that is accessible at:
http://zopebuildout.whq.gocept.com
- builds are run when the trunk of a buildout-based project is changed and at 3am CEST every day.
- Updates for the project list are run before the nightly build and pick up all projects' trunks that define a buildout.cfg
- Currently, all projects that don't define a test runner will appear as broken. I'll fix that soon so that non-existing test runners will be ignored.
Christian
Hi, David Pratt schrieb:
Hi Christian. How difficult was this to get running. I am considering a a local buildbot for my own code. The structure of my repository emulates the structure of svn.zope.org. Many thanks.
Semi-hard. The actual buildout configuration script and repository sniffing took some time. I'm not sure I checked this configuration in, but I'm holding a previous version in my Sandbox on zope.org. Christian -- gocept gmbh & co. kg - forsterstrasse 29 - 06112 halle (saale) - germany www.gocept.com - ct@gocept.com - phone +49 345 122 9889 7 - fax +49 345 122 9889 1 - zope and plone consulting and development
Thanks Christian. I am interested in this. Are there significant changes to what you are doing now? I'll checkout what you have in the Sandbox in the interim. Many thanks. Regards, David Christian Theune wrote:
Hi,
David Pratt schrieb:
Hi Christian. How difficult was this to get running. I am considering a a local buildbot for my own code. The structure of my repository emulates the structure of svn.zope.org. Many thanks.
Semi-hard. The actual buildout configuration script and repository sniffing took some time. I'm not sure I checked this configuration in, but I'm holding a previous version in my Sandbox on zope.org.
Christian
participants (6)
-
Chris Withers -
Christian Theune -
David Pratt -
Jodok Batlogg -
Marius Gedminas -
Tres Seaver