freeze build slave
I have created a buildbot configuration to test freeze. At the moment, it has only one builder: http://buildbot.python.org/all/waterfall?show=AMD64%20Ubuntu%20LTS%20Freeze%... which currently fails as freeze doesn't actually work. The test itself works by first building Python in release mode, then installing it, then running freeze on a test program, then building the test programm (and ultimately running it). The question then is: how should that integrate with the rest of the builders? I can see three alternatives: A. (status quo) run the test on a selected subset of the Unix builders B. run the test on all Unix builders. C. integrate the test with the Unix regular Unix builder Evaluating these alternatives: B: pro: wider testing con: each such build takes the slave lock, so slaves will have to do one additional full build per commit (or two if the fix gets checked into 3.4 as well). In addition, each slave will need disk space for one additional build tree plus one Python installation, per branch. C: pro: compared to B, build time is reduced (need only to build once per branch); disk space is also reduced con: it would test a debug build, not a release build Regards, Martin
On Sun, 30 Mar 2014 20:44:02 +0200
"Martin v. Löwis"
I have created a buildbot configuration to test freeze. At the moment, it has only one builder:
http://buildbot.python.org/all/waterfall?show=AMD64%20Ubuntu%20LTS%20Freeze%...
which currently fails as freeze doesn't actually work.
The test itself works by first building Python in release mode, then installing it, then running freeze on a test program, then building the test programm (and ultimately running it).
The question then is: how should that integrate with the rest of the builders? I can see three alternatives: A. (status quo) run the test on a selected subset of the Unix builders B. run the test on all Unix builders. C. integrate the test with the Unix regular Unix builder
Evaluating these alternatives: B: pro: wider testing con: each such build takes the slave lock, so slaves will have to do one additional full build per commit (or two if the fix gets checked into 3.4 as well). In addition, each slave will need disk space for one additional build tree plus one Python installation, per branch. C: pro: compared to B, build time is reduced (need only to build once per branch); disk space is also reduced con: it would test a debug build, not a release build
We have at least one builder working in release (i.e. non-debug) mode. http://buildbot.python.org/all/builders/x86%20Gentoo%20Non-Debug%203.x Regards Antoine.
"Martin v. L?wis"
C: pro: compared to B, build time is reduced (need only to build once per branch); disk space is also reduced con: it would test a debug build, not a release build
It would be an option to run half of the Unix slaves (especially the ones with the more aggressive compilers) in release mode. I think that is beneficial anyway. Stefan Krah
I disagree. Running tests in debug code tests more things thanks to
assertions, and provides more info in case of test failure or crash. Some
assertions only fail on some platforms. See for example test_locale which
fails with an assertion error on solaris (since Python 3.3).
Adding one or two slaves should not hurt. You need maybe at least one on
Windows and another on OS X.
Victor
Le dimanche 30 mars 2014, Stefan Krah
"Martin v. L?wis"
javascript:;> wrote: C: pro: compared to B, build time is reduced (need only to build once per branch); disk space is also reduced con: it would test a debug build, not a release build
It would be an option to run half of the Unix slaves (especially the ones with the more aggressive compilers) in release mode. I think that is beneficial anyway.
Stefan Krah
_______________________________________________ Python-Dev mailing list Python-Dev@python.org javascript:; https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/victor.stinner%40gmail.co...
participants (4)
-
"Martin v. Löwis"
-
Antoine Pitrou
-
Stefan Krah
-
Victor Stinner