Re: [Maria-developers] Maria binary builds
From what I have seen of Buildbot so far, I am hopeful that it will be sufficient for our needs. It seems to have all of the right ideas, and many of
Hi Vadim, Just an update on what I have been doing with binaries and Buildbot. I have now set up Buildbot to build and test our trees on Launchpad after every push (similar to Pushbuild at MySQL/Sun if you are familiar with that): http://askmonty.org/buildbot/index.html For now we have only few (one) build slave. The plan of course is to add more, hopefully some of them volunteered from the community (hint :-). I would be happy to make the infrastructure available to you as well, ie. to set it up to also track your Launcpad trees and build on your build slaves with your scripts and options. But you may prefer to control the buildbot master yourself; just let me know if you need a copy of my Buildbot configuration files or if I can help with any questions in setting it up. I am currently working on getting all existing test failures visible in the Buildbot runs fixed (Valgrind errors mostly). After that (next week I hope) I plan to turn to working on getting Buildbot to also produce binaries. I will need to do some research in which platforms we need to build for (Debian/Ubuntu/CentOS/Suse/Generic? x86/amd64? Any others?), and which configure / build options to use. Any help you can provide here would be much appreciated. I have lots of experience with scripting this kind of thing, but less so with the details of how people actually use the binaries and what they need (I have mostly build from source myself even for production). I also plan to look at what official Debian/Ubuntu packages provide, and at the scripts from OurDelta. My vision is to have production and test of binaries fully integrated into our Buildbot infrastructure. I want it fully automated, so that binaries are made after every push, and so that problems with the binaries are dealt with as an integrated part of development just like any other problem. Ideally, releasing binaries would then just be a matter of picking the right files from the buildbot archives. It will take some work to get there of course, but at least that is the vision. the necessary features are already there. Some stuff will be missing, and my plan is to spend the time to extend it as needed. So for concrete plans next week, these currently are: 1. Setup build of generic binaries (.tar.gz) for Linux x86/amd64. For this I need to understand better how to deal with external dependencies. Should I link statically with libc? My impression is not to do this as I think this causes big problems with any type of plugin, but I also seem to recall that existing generic packages do this. Alternatively, I need to understand which version of glibc to use. 2. Work on getting build slave machines set up for this. 3. Get a first version running on Buildbot that produces the binaries. After this I think will be Debian and Ubuntu binaries with apt-able repositories, and then RPMs. I think that's it for an update of current plans. Let me know if you have any questions/comments/suggestions. Especially any help on exact CFLAGS and ./configure arguments to use would be very helpful. - Kristian.
I have two idle machines, one Debian lenny x86-64 and the other alpha. How can I help by adding these to the build pool? Is there interest in alpha? -------------------------- Cheers, Adam On Apr 6, 2009, at 9:13, Kristian Nielsen <knielsen@knielsen-hq.org> wrote:
Hi Vadim,
Just an update on what I have been doing with binaries and Buildbot.
I have now set up Buildbot to build and test our trees on Launchpad after every push (similar to Pushbuild at MySQL/Sun if you are familiar with that):
http://askmonty.org/buildbot/index.html
For now we have only few (one) build slave. The plan of course is to add more, hopefully some of them volunteered from the community (hint :-).
I would be happy to make the infrastructure available to you as well, ie. to set it up to also track your Launcpad trees and build on your build slaves with your scripts and options. But you may prefer to control the buildbot master yourself; just let me know if you need a copy of my Buildbot configuration files or if I can help with any questions in setting it up.
I am currently working on getting all existing test failures visible in the Buildbot runs fixed (Valgrind errors mostly).
After that (next week I hope) I plan to turn to working on getting Buildbot to also produce binaries.
I will need to do some research in which platforms we need to build for (Debian/Ubuntu/CentOS/Suse/Generic? x86/amd64? Any others?), and which configure / build options to use. Any help you can provide here would be much appreciated. I have lots of experience with scripting this kind of thing, but less so with the details of how people actually use the binaries and what they need (I have mostly build from source myself even for production). I also plan to look at what official Debian/Ubuntu packages provide, and at the scripts from OurDelta.
My vision is to have production and test of binaries fully integrated into our Buildbot infrastructure. I want it fully automated, so that binaries are made after every push, and so that problems with the binaries are dealt with as an integrated part of development just like any other problem. Ideally, releasing binaries would then just be a matter of picking the right files from the buildbot archives. It will take some work to get there of course, but at least that is the vision.
From what I have seen of Buildbot so far, I am hopeful that it will be sufficient for our needs. It seems to have all of the right ideas, and many of the necessary features are already there. Some stuff will be missing, and my plan is to spend the time to extend it as needed.
So for concrete plans next week, these currently are:
1. Setup build of generic binaries (.tar.gz) for Linux x86/amd64. For this I need to understand better how to deal with external dependencies. Should I link statically with libc? My impression is not to do this as I think this causes big problems with any type of plugin, but I also seem to recall that existing generic packages do this. Alternatively, I need to understand which version of glibc to use.
2. Work on getting build slave machines set up for this.
3. Get a first version running on Buildbot that produces the binaries.
After this I think will be Debian and Ubuntu binaries with apt-able repositories, and then RPMs.
I think that's it for an update of current plans. Let me know if you have any questions/comments/suggestions. Especially any help on exact CFLAGS and ./configure arguments to use would be very helpful.
- Kristian.
_______________________________________________ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
Kristian, If you can share your Buildbot configuration that would be perfect! As for platforms we see demand for Debian/Ubuntu/CentOS both 32bit and 64bit. Also quite often are mentioned FreeBSD, MacOS and Windows. For CFLAGS / configure I found combination from MySQL .spec for RedHat 5 works almost fine. The changes I made for CFLAGS I am adding next combination: -O2 -g -fno-omit-frame-pointer it makes life to debugs hangs / crashes easier. Thanks! Vadim Kristian Nielsen wrote:
Hi Vadim,
Just an update on what I have been doing with binaries and Buildbot.
I have now set up Buildbot to build and test our trees on Launchpad after every push (similar to Pushbuild at MySQL/Sun if you are familiar with that):
http://askmonty.org/buildbot/index.html
For now we have only few (one) build slave. The plan of course is to add more, hopefully some of them volunteered from the community (hint :-).
I would be happy to make the infrastructure available to you as well, ie. to set it up to also track your Launcpad trees and build on your build slaves with your scripts and options. But you may prefer to control the buildbot master yourself; just let me know if you need a copy of my Buildbot configuration files or if I can help with any questions in setting it up.
I am currently working on getting all existing test failures visible in the Buildbot runs fixed (Valgrind errors mostly).
After that (next week I hope) I plan to turn to working on getting Buildbot to also produce binaries.
I will need to do some research in which platforms we need to build for (Debian/Ubuntu/CentOS/Suse/Generic? x86/amd64? Any others?), and which configure / build options to use. Any help you can provide here would be much appreciated. I have lots of experience with scripting this kind of thing, but less so with the details of how people actually use the binaries and what they need (I have mostly build from source myself even for production). I also plan to look at what official Debian/Ubuntu packages provide, and at the scripts from OurDelta.
My vision is to have production and test of binaries fully integrated into our Buildbot infrastructure. I want it fully automated, so that binaries are made after every push, and so that problems with the binaries are dealt with as an integrated part of development just like any other problem. Ideally, releasing binaries would then just be a matter of picking the right files from the buildbot archives. It will take some work to get there of course, but at least that is the vision.
From what I have seen of Buildbot so far, I am hopeful that it will be sufficient for our needs. It seems to have all of the right ideas, and many of the necessary features are already there. Some stuff will be missing, and my plan is to spend the time to extend it as needed.
So for concrete plans next week, these currently are:
1. Setup build of generic binaries (.tar.gz) for Linux x86/amd64. For this I need to understand better how to deal with external dependencies. Should I link statically with libc? My impression is not to do this as I think this causes big problems with any type of plugin, but I also seem to recall that existing generic packages do this. Alternatively, I need to understand which version of glibc to use.
2. Work on getting build slave machines set up for this.
3. Get a first version running on Buildbot that produces the binaries.
After this I think will be Debian and Ubuntu binaries with apt-able repositories, and then RPMs.
I think that's it for an update of current plans. Let me know if you have any questions/comments/suggestions. Especially any help on exact CFLAGS and ./configure arguments to use would be very helpful.
- Kristian.
-- Vadim Tkachenko, CTO Percona Inc. ICQ: 369-510-335, Skype: vadimtk153, Phone +1-888-401-3403 MySQL Performance Blog - http://www.mysqlperformanceblog.com MySQL Consulting http://www.percona.com/ Attend the 2009 Percona Performance Conference April 22-23 - http://conferences.percona.com/
Vadim Tkachenko <vadim@percona.com> writes:
If you can share your Buildbot configuration that would be perfect! As for platforms we see demand for Debian/Ubuntu/CentOS both 32bit and 64bit. Also quite often are mentioned FreeBSD, MacOS and Windows.
Ok, it's attached. Just let me know if you have any questions on it. I'm using the Debian/Ubuntu buildbot package, which runs buildbot as user `buildbot`. I found it useful to set $HOME to the buildbot home directory in /etc/default/buildbot. Without this, buildbot tended to pick up the wrong ~/.bazaar directory and use the wrong configuration, causing me problems. I also run a `bzr init-repo` on the build slave directories before starting them. This makes bzr only download the new changes from Launchpad, not the whole history for every build.
For CFLAGS / configure I found combination from MySQL .spec for RedHat 5 works almost fine. The changes I made for CFLAGS I am adding next combination:
-O2 -g -fno-omit-frame-pointer
it makes life to debugs hangs / crashes easier.
Ok, thanks a lot for the information. I am still not sure whether generic (.tar.gz) binaries should be build statically (and to what extend). I am BTW. also talking with Arjen (OurDelta / Open Query), he also has some ideas about what to do for binaries. I'm not sure how much Percona is working with him currently. - Kristian. # -*- python -*- # ex: set syntax=python: # This is a sample buildmaster config file. It must be installed as # 'master.cfg' in your buildmaster's base directory (although the filename # can be changed with the --basedir option to 'mktap buildbot master'). # It has one job: define a dictionary named BuildmasterConfig. This # dictionary has a variety of keys to control different aspects of the # buildmaster. They are documented in docs/config.xhtml . # This is the dictionary that the buildmaster pays attention to. We also use # a shorter alias to save typing. c = BuildmasterConfig = {} ####### BUILDSLAVES # the 'slaves' list defines the set of allowable buildslaves. Each element is # a tuple of bot-name and bot-password. These correspond to values given to # the buildslave's mktap invocation. from buildbot.buildslave import BuildSlave c['slaves'] = [BuildSlave("valgrind", "xxx", max_builds=1) ,BuildSlave("pcrews-win", "xxx", max_builds=1) ,BuildSlave("centos5", "xxx", max_builds=1) ,BuildSlave("archivist-cnc", "xxx", max_builds=1) ,BuildSlave("archivist-amd64", "xxx", max_builds=1) ,BuildSlave("adutko-amd64", "xxx", max_builds=1) ,BuildSlave("adutko-alpha", "xxx", max_builds=1) ] # to limit to two concurrent builds on a slave, use # c['slaves'] = [BuildSlave("bot1name", "bot1passwd", max_builds=2)] # 'slavePortnum' defines the TCP port to listen on. This must match the value # configured into the buildslaves (with their --master option) c['slavePortnum'] = 9989 ####### CHANGESOURCES # the 'change_source' setting tells the buildmaster how it should find out # about source code changes. Any class which implements IChangeSource can be # put here: there are several in buildbot/changes/*.py to choose from. from bzr_buildbot import BzrPoller bzr_5_1 = BzrPoller(url="http://bazaar.launchpad.net/%7Emaria-captains/maria/5.1", poll_interval=5*60, branch_name="5.1") bzr_5_2 = BzrPoller(url="http://bazaar.launchpad.net/%7Emaria-captains/maria/5.2", poll_interval=5*60, branch_name="5.2") bzr_6_0 = BzrPoller(url="http://bazaar.launchpad.net/%7Emaria-captains/maria/6.0", poll_interval=5*60, branch_name="6.0") c['change_source'] = [bzr_5_1, bzr_5_2, bzr_6_0] # For example, if you had CVSToys installed on your repository, and your # CVSROOT/freshcfg file had an entry like this: #pb = ConfigurationSet([ # (None, None, None, PBService(userpass=('foo', 'bar'), port=4519)), # ]) # then you could use the following buildmaster Change Source to subscribe to # the FreshCVS daemon and be notified on every commit: # #from buildbot.changes.freshcvs import FreshCVSSource #fc_source = FreshCVSSource("cvs.example.com", 4519, "foo", "bar") #c['change_source'] = fc_source # or, use a PBChangeSource, and then have your repository's commit script run # 'buildbot sendchange', or use contrib/svn_buildbot.py, or # contrib/arch_buildbot.py : # #from buildbot.changes.pb import PBChangeSource #c['change_source'] = PBChangeSource() ####### SCHEDULERS ## configure the Schedulers from buildbot.scheduler import AnyBranchScheduler c['schedulers'] = [] c['schedulers'].append(AnyBranchScheduler( name="mariadb", branches=["5.1", "5.2", "6.0"], treeStableTimer=1, # 1 sec for bzr builderNames=["valgrind", "centos5-debug", "archivist-cnc", "archivist-amd64", "adutko-amd64", "adutko-alpha"])) ####### BUILDERS # the 'builders' list defines the Builders. Each one is configured with a # dictionary, using the following keys: # name (required): the name used to describe this bilder # slavename (required): which slave to use, must appear in c['bots'] # builddir (required): which subdirectory to run the builder in # factory (required): a BuildFactory to define how the build is run # periodicBuildTime (optional): if set, force a build every N seconds # buildbot/process/factory.py provides several BuildFactory classes you can # start with, which implement build processes for common targets (GNU # autoconf projects, CPAN perl modules, etc). The factory.BuildFactory is the # base class, and is configured with a series of BuildSteps. When the build # is run, the appropriate buildslave is told to execute each Step in turn. # the first BuildStep is typically responsible for obtaining a copy of the # sources. There are source-obtaining Steps in buildbot/process/step.py for # CVS, SVN, and others. cvsroot = ":pserver:anonymous@cvs.sourceforge.net:/cvsroot/buildbot" cvsmodule = "buildbot" from buildbot.process import factory from buildbot.steps.source import Bzr from buildbot.steps.shell import Compile, Test f1 = factory.BuildFactory() f1.addStep(Bzr(baseURL="http://bazaar.launchpad.net/%7Emaria-captains/maria/", defaultBranch="5.1", mode="copy")) f1.addStep(Compile(command=["BUILD/compile-pentium64-valgrind-max"])) f1.addStep(Test(command=["sh", "-c", "cd mysql-test && exec perl mysql-test-run.pl --mem --parallel=2 --valgrind --force --skip-ndb"])) bld_valgrind = {'name': "valgrind", 'slavename': "valgrind", 'builddir': "valgrind", 'factory': f1, } f_dbg_2_64 = factory.BuildFactory() f_dbg_2_64.addStep(Bzr(baseURL="http://bazaar.launchpad.net/%7Emaria-captains/maria/", defaultBranch="5.1", mode="copy")) f_dbg_2_64.addStep(Compile(command=["BUILD/compile-pentium64-debug-max"])) f_dbg_2_64.addStep(Test(command=["sh", "-c", "cd mysql-test && exec perl mysql-test-run.pl --parallel=2 --force --skip-ndb"])) f_dbg_1_32 = factory.BuildFactory() f_dbg_1_32.addStep(Bzr(baseURL="http://bazaar.launchpad.net/%7Emaria-captains/maria/", defaultBranch="5.1", mode="copy")) f_dbg_1_32.addStep(Compile(command=["BUILD/compile-pentium-debug-max"])) f_dbg_1_32.addStep(Test(command=["sh", "-c", "cd mysql-test && exec perl mysql-test-run.pl --force --skip-ndb"])) bld_linux_debug = {'name': "centos5-debug", 'slavename': "centos5", 'builddir': "centos5-debug", 'factory': f_dbg_2_64, } bld_archivist_cnc = {'name': "archivist-cnc", 'slavename': "archivist-cnc", 'builddir': "archivist-cnc", 'factory': f_dbg_1_32, } bld_archivist_amd64 = {'name': "archivist-amd64", 'slavename': "archivist-amd64", 'builddir': "archivist-amd64", 'factory': f_dbg_2_64, } bld_adutko_amd64 = {'name': "adutko-amd64", 'slavename': "adutko-amd64", 'builddir': "adutko-amd64", 'factory': f_dbg_2_64, } f_dbg_alpha = factory.BuildFactory() f_dbg_alpha.addStep(Bzr(baseURL="http://bazaar.launchpad.net/%7Emaria-captains/maria/", defaultBranch="5.1", mode="copy")) f_dbg_alpha.addStep(Compile(command=["BUILD/compile-alpha"])) f_dbg_alpha.addStep(Test(command=["sh", "-c", "cd mysql-test && exec perl mysql-test-run.pl --force --skip-ndb"])) bld_adutko_alpha = {'name': "adutko-alpha", 'slavename': "adutko-alpha", 'builddir': "adutko-alpha", 'factory': f_dbg_alpha, } c['builders'] = [bld_valgrind, bld_linux_debug, bld_archivist_cnc, bld_archivist_amd64, bld_adutko_amd64, bld_adutko_alpha] ####### STATUS TARGETS # 'status' is a list of Status Targets. The results of each build will be # pushed to these targets. buildbot/status/*.py has a variety to choose from, # including web pages, email senders, and IRC bots. c['status'] = [] from buildbot.status import html c['status'].append(html.WebStatus(http_port=8010, allowForce=True)) # from buildbot.status import mail # c['status'].append(mail.MailNotifier(fromaddr="buildbot@localhost", # extraRecipients=["builds@example.com"], # sendToInterestedUsers=False)) # # from buildbot.status import words # c['status'].append(words.IRC(host="irc.example.com", nick="bb", # channels=["#example"])) # # from buildbot.status import client # c['status'].append(client.PBListener(9988)) ####### DEBUGGING OPTIONS # if you set 'debugPassword', then you can connect to the buildmaster with # the diagnostic tool in contrib/debugclient.py . From this tool, you can # manually force builds and inject changes, which may be useful for testing # your buildmaster without actually commiting changes to your repository (or # before you have a functioning 'sources' set up). The debug tool uses the # same port number as the slaves do: 'slavePortnum'. #c['debugPassword'] = "debugpassword" # if you set 'manhole', you can ssh into the buildmaster and get an # interactive python shell, which may be useful for debugging buildbot # internals. It is probably only useful for buildbot developers. You can also # use an authorized_keys file, or plain telnet. #from buildbot import manhole #c['manhole'] = manhole.PasswordManhole("tcp:9999:interface=127.0.0.1", # "admin", "password") ####### PROJECT IDENTITY # the 'projectName' string will be used to describe the project that this # buildbot is working on. For example, it is used as the title of the # waterfall HTML page. The 'projectURL' string will be used to provide a link # from buildbot HTML pages to your project's home page. c['projectName'] = "MariaDB" c['projectURL'] = "https://launchpad.net/maria" # the 'buildbotURL' string should point to the location where the buildbot's # internal web server (usually the html.Waterfall page) is visible. This # typically uses the port number set in the Waterfall 'status' entry, but # with an externally-visible host name which the buildbot cannot figure out # without some help. c['buildbotURL'] = "http://askmonty.org/buildbot/"
participants (3)
-
Adam M Dutko
-
Kristian Nielsen
-
Vadim Tkachenko