BuildAPI-app is almost up!

I am very close to having the buildapi-app docker container working completely. I left off last not having selfserve-agent setup, and having a kombu error.

In order to setup selfserve-agent properly, I had to include a selfserve-agent.ini file in the base of the docker file to be used by when called with: python buildapi/buildapi/scripts/ -w; Additionally, I included a simple bash script to ensure that the container is able to launch both processes side by side without blocking one another.

The error I was having with kombu was because I did not have rabbitmq-app running. Kombu is used (as carrot was before) to make a connection to the amqp that rabbitmq sets up as an mq. After getting rabbitmq-app up, it needed to be linked with buildapi-app, and once it was it became clear that localhost was not the proper host for buildapi or selfserve-agent to attempt to find the amqp. When docker links containers, it allocates all the ports and IPs for them. It makes these new connections available to you in the form of environment variables. Once I had the 2 apps up and linked by running:

docker run -d -p 5672:5672 -p 15672:15672 -p 4369:4369 -name rabbitmq rabbitmq-app

docker run -t -i -p 8888:8888 -link rabbitmq:mq -name buildapi buildapi-app /bin/bash     # bash so that I can play with the variables

Then I was able to run env and see the environment variables that docker setup:


As you can see the proper host to look at is instead of localhost. Luckily, since these are environment variables, we can just insert them into our configs by name, rather than hard coding them.

After this step, I was still getting a kombu error, which was caused by not having proper login credentials for the amqp. In order to fix this I had to add a userid and password to the config.ini and selfserve-agent.ini files in buildapi. However, buildapi/buildapi/lib/ does not open the kombu connection with the userid and password parameters filed in, so I had to patch this file. I also opened a bug to handle this patch, or to have documentation generated for the proper procedure. The patch is simply:

@@ -21,16 +21,18 @@ import logging
 log = logging.getLogger(__name__)
 class ConfigMixin(object):
     def setup_config(self, config):
         self.heartbeat = int(config.get('mq.heartbeat_interval', '0'))
         conn = Connection(config['mq.kombu_url'],
+                          userid=config['mq.userid'],
+                          password=config['mq.password'],
                           transport_options={'confirm_publish': True})
         self.connection = connections[conn].acquire(block=True) = Exchange(config[''], type='topic', durable=True)
     def get_queue(self, queue_name, routing_key):
         return Queue(queue_name,

Once all of this was fixed and setup, it appears that buildapi and selfserve-agent were able to connect to the amqp perfectly fine!

Left to do on buildapi-app is to:

  • Test that buildapi and selfserve-agent are truly connected and able to exchange over the amqp
  • Setup the databases properly and load them with temporary data
  • Test the entire buildapi application by running similar procedures that should work in my local setup

Updates to this setup can again be found in my user repo

Tagged with: , , , , , , , , , ,
Posted in Daily Updates

Docker containers up for RabbitMQ and BuildAPI

After spending some time on the buildapi-app docker container, I realized that my issues with kombu were likely due to selfservagent setup stuff that I have not yet done. So before diving into that I went ahead and started getting rabbitmq working. I referenced the following while working on rabbitmq-app and buildapi-app:

I finally worked the app to the point that rabbitmq was up and all the proper users were installed. However, I was not able to access the RabbitMQ management page as I should have been able to at
I began flipping through the boot2docker tutorial again and I noticed that the final step to launching the app was to run the following sequence of commands

$ boot2docker down # The VM must be stopped
$ vboxmanage modifyvm boot2docker-vm –natpf1 "http,tcp,,8888,,8888"
$ boot2docker up

When I initially did this tutorial, I noticed that the vboxmanage command seemed to be connecting host port 8888 and guest port 8888, but I didn't give it much more thought. Well it turns out my initial understanding of using Boot2Docker was incorrect. Boot2docker is simply running a VM in vbox called boot2docker-vm, and within this vm is an environment with docker fully installed and working. This is important because I was under the impression that my docker containers were running in my env and not in a vm themselves. Because of this misunderstanding, I was puzzled as to why I needed to run this vboxmanage command to expose port 8888 on the guest and host, after I had already exposed port 8888 in the Dockerfile of the tutorial, and launched the container with the command docker run -p 8888:8888.

Silly me, the true structure is that
1) the exposed port in the Dockerfile tells the docker container to make 8888 available for exposing, and
2) the command docker run -p 8888:8888 does the connecting of port 8888 in the docker container with port 8888 IN THE BOOT2DOCKER-VM
This seems obvious now, but I apparently had overlooked this simple concept. The container's port was connected just fine to the boot2docker-vm, but I couldn't see them on my own local OS because I hadn't proceeded to forward the ports from the boot2docker-vm to my local machine!

Once I discovered my mistake, I ran the command vboxmanage showvminfo boot2docker-vm and was greeted with a ton of info about the vm, including the following:

NIC 1: MAC: 0800279C9CFD, Attachment: NAT, Cable connected: on, Trace: off (file: none), Type: virtio, Reported speed: 0 Mbps, Boot priority: 0, Promisc Policy: deny, Bandwidth group: none
NIC 1 Settings:  MTU: 0, Socket (send: 64, receive: 64), TCP Window (send:64, receive: 64)
NIC 1 Rule(0):   name = docker, protocol = tcp, host ip =, host port = 5000, guest ip = , guest port = 4243
NIC 1 Rule(1):   name = http, protocol = tcp, host ip =, host port = 8888, guest ip = , guest port = 8888
NIC 1 Rule(2):   name = ssh, protocol = tcp, host ip =, host port = 2022, guest ip = , guest port = 22
NIC 2:           disabled
NIC 3:           disabled
NIC 4:           disabled
NIC 5:           disabled
NIC 6:           disabled
NIC 7:           disabled
NIC 8:           disabled

The line reading NIC 1 Rule(1) shows the results of setting host port 8888 and guest port 8888

You cannot set more than 1 http rule for NIC 1 (perhaps you can enable NIC 2 and set the http rule there, but I didn't bother with it), so I deleted the previous NIC 1 http rule and added one for port 15672 so that I could test the presence of the rabbitmq management portal at

$ boot2docker down
$ vboxmanage modifyvm boot2docker-vm –natpf1 delete http
$ vboxmanage modifyvm boot2docker-vm –natpf1 "http,tcp,,15672,,15672"
$ boot2docker up

After a rebuild/launch of rabbitmq-app, I visited and was greeted with the management portal! Huzzah!
With that I was able to verify that the rabbitmq-app was finished!

From there I needed to ensure that the buildapi-app container could connect to the rabbitmq-app container, so I deleted port 15672 from the NIC 1 http rule and added port 8888 again so that I could visit the buildapi page there. (Yes I could have kept 15672)

In order to get these containers communicating, I needed specify a link between them, and I used these docs to help me figure that part out.

I was able to confirm that buildapi is up and running and pages can be visited in self-serve, though there is no db info so no revisions show up, but that is as expected since I am not feeding in anything to fill those dbs with data. Left to do on the buildapi-app container is to get kombu and selfserveagent running.

I have uploaded the current working Dockerfiles for these apps to

Bash commands that were useful today:

for f in $(docker ps -a -q); do docker rm -f $f; done; # Remove all docker containers
for f in $(docker images -q); do docker rmi -f $f; done; # Remove all docker images


Tagged with: , , , , , , , , , , ,
Posted in Daily Updates

Building BuildAPI Docker app

I am working through building up the BuildAPI Docker app that is going to live and work in Vagrant with the other apps. Currently I have things to the stage where buildapi is fully installed, and running but am having problems with kombu.

I have run into these issues before, when I was configuring kombu for the first time on my local machine. When I run docker build -t buildapi-app . and then docker run -i -p 5000:5000 -t buildapi-app the app starts up fine, but I see the following message about kombu:

localhost:buildapi-app jzeller$ docker run -i -p 5000:5000 -t buildapi-app
Starting subprocess with file monitor
Running reloading file monitor
Starting server in PID 7.
2014-04-16 05:51:00,389 WARNI [] [Dummy-2] Kombu connection failed ([Errno 111] Connection refused); waiting 2s
serving on view at
2014-04-16 05:51:02,396 WARNI [] [Dummy-2] Kombu connection failed ([Errno 111] Connection refused); waiting 4s
2014-04-16 05:51:06,407 WARNI [] [Dummy-2] Kombu connection failed ([Errno 111] Connection refused); waiting 6s
2014-04-16 05:51:12,419 WARNI [] [Dummy-2] Kombu connection failed ([Errno 111] Connection refused); waiting 8s

Here is the current Dockerfile for buildapi-app:

FROM ubuntu:precise
MAINTAINER Chirs Atlee <>
MAINTAINER John Zeller <>

# Install base dependencies
RUN apt-get -q update
RUN apt-get -y -q install python-dev mercurial sudo python-pip subversion wget curl make python-virtualenv libmysqlclient-dev sqlite3

# Install Python Google Visualizations 1.7.1
RUN pip install -e svn+

# Install BuildAPI
RUN hg clone

# Install pip requirements with pip install
RUN curl | python; rm *.tar.gz;
RUN pip install -r buildapi/rtfd-requirements.txt
RUN pip install kombu==3.0.12 MySQL-python==1.2.3 python-memcached pytz==2011h

# Setup app
RUN cd buildapi; python develop; paster make-config buildapi config.ini
RUN cd buildapi; sed 's/buildapi.cache = redis:HOSTNAME:PORT/buildapi.cache = memcached:' config.ini > tmp; rm config.ini; mv tmp config.ini

# Setup sqlite dbs
#RUN cd buildapi; sqlite3 statusdb.sqlite3 < statusdb_schema.sql
#RUN cd buildapi; sqlite3 schedulerdb.sqlite3 < schedulerdb_schema.sql
#RUN cd buildapi; sqlite3 buildapi.sqlite3 < buildapi_schema.sql

# Setup Kombu
RUN cd buildapi; sed 's/mq.kombu_url =/mq.kombu_url = localhost/' config.ini > tmp; rm config.ini; mv tmp config.ini


CMD ["paster", "serve", "--reload", "-v", "buildapi/config.ini"]

Tagged with: , , , , , , , , , ,
Posted in Daily Updates

Further Steps with Vagrant

Today I spent a bunch of time looking into how to setup a vagrant instance, how to pack it with docker, how to run multiple docker containers in that vagrant instance and how to link them all together to play nicely. Throughout this process I have narrowed down that vagrant will be running hashicorp/precise64, and docker will have 5 apps, one each for buildapi, mysql , redis, rabbitmq and buildbot. Once I have linked all of this together properly, there will be a directory structure that looks a little like this:







The Vagrantfile will load a base image of Ubuntu 12.04 Precise 64-bit, install docker (tip), build the images for buildapi (tip), mysql (tip), redis (v2.4.5), rabbitmq (tip) and buildbot (tip), expose all the necessary ports for each and link them properly, and then run each container as a daemon. Once this is all setup the user should be able to simply pull this repo (I am assuming this directory will become a repository on, run "vagrant up" and then they will be able to see buildapi at and buildbot at The awesome added benefit to this is that files can be shared between your normal development environment and the VM that vagrant started up, simply by placing and editing files in the base directory where Vagrantfile exists! This will make development of these apps a lot smoother for our community members, with the super simple push button command line interface that vagrant provides for getting these VMs started up. Additionally, once this works it can easily be expanded with more and more apps as we see fit to add them to this Vagrant instance! :)

Tagged with: , , , , , , ,
Posted in Daily Updates

Vagrant + Docker = Happy Fun Times!

I am working with Vagrant and Docker for the first time, and it is awesome! We are working towards capturing all of our "how to install" knowledge for buildbot, buildapi and redis in code by making a set of docker containers that can play well together inside of Vagrant. In this setup, we are assuming that the user has Ubuntu (or equivalent linux) in a virtualbox running. Once that 1 VM exists we are to have separate docker instances per app (buildbot, buildapi, redis, etc.). The benefit of connecting these docker instances inside vagrant to play together, is that it lets any combo of buildbot, buildapi standalone, or "system" to be run. This also allows more modules to be added later. 

So far I have installed Vagrant, Docker and Boot2Docker, worked my way through the Boot2Docker/Docker tutorials (including a sweet hello world app example from David Dias), and I have begun working my way through the Vagrant tutorials. Other than all that prep, I have also begun writing up the Dockerfiles needed to setup each of our apps. I think we will need one each for:

I got most of the way through the BuildAPI and RabbitMQ Dockerfile's before I got to a point where I needed to get Vagrant installed and figured out so that I could also then create a Vagrantfile to go along with this entire setup.

Once I have completed this entire setup, you will be able to get a buildapi, buildbot, redis, rabbitmq, and selfserve system up and running simply by downloading the Vagrantfile and running 'vagrant up'. How cool is that?!

More updates on this next week!

Useful links:

Tagged with: , , , , , , ,
Posted in Daily Updates

Triggering of Arbitrary builds/tests is now possible!

Bug 793989 requests the ability of buildapi's self-serve to be able to request arbitrary builds/tests on a given push, and this is now possible! If you are interested in triggering an arbitrary build/test you can start with this simple python script to get you started.

This new buildapi REST functionality takes a POST request with the parameters properties and files, as a dictionary and list, respectively. The REST URL is built as{branch}/builders/{buildername}/{revision} where {branch} is a valid branch, {revision} is an existing revision on that branch, and {buildername} is the arbitrary build/test that you wish to trigger. Examples of appropriate buildernames are "Ubuntu VM 12.04 try opt test mochitest-1" or "Linux x86-64 try build"; Any buildername that shows up in the builder column on buildapi should work. Please file a bug if you find any exceptions!

As a specific example, if you are launching the test "Ubuntu VM 12.04 x64 try opt test jetpack" after having run the build "Linux x86-64 try build", then you need to supply the files list parameter as ["", ""].

Once you have submitted an arbitrary build/test request, you can see the status of that build/test on BuildAPI in multiple locations. The one which allows you to see which masters have grabbed the build/test, you can use the following URL:{branch}-selfserve/{revision}, where obviously {branch} is the branch you submitted your request on and {revision} is the revision you submitted on that branch.

NOTE: Currently TBPL is not showing the pending/running status of builds/tests started with this new BuildAPI functionality because of some issues outlined in Bug 981825, however once a build/test that was triggered with this new functionality is finished, it shows up on TBPL just as you would expect any other build/test to.

Tagged with: ,
Posted in Mozilla

Docs, MySQL Dumps, Buildbot Recap

It's been a few days since my last update, so here it is!

  1. I finished writing up the docs addition for setting up a local buildbot instance
  2. Ran a manual table-by-table mysql dump on my local snapshots of statusdb and schedulerdb, which successfully shrunk their collective size from 108gb to 14.5gb, or by 86.6%! So these snapshots are alot easier to deal with. They currently only show the build data from July 8th 02:00:00 GMT to July 16th ~12:00:00 GMT, which is plenty for my current dev enviromment setup.
  3. Adjusted the master.cfg file for build-master in Buildbot to use the mysql schedulerdb on my local system, rather than the default sqlite:///state.sqlite

    • Changed line 143 of master.cfg from c['db_url'] = “sqlite:///state.sqlite” to c['db_url'] = "mysql://buildbot:buildbot@localhost/temp_schedulerdb"

      • NOTE: The regex does not like a mysql user that has no password. Originally, I had specified root: , ie "mysql://root:@localhost/temp_schedulerdb", so I made a new user named buildbot, password buildbot.
    • Ran pip install MySQL-python==1.2.3 from the buildbot virtualenv… found this via pip freeze from my already existing buildapi virtualenv
    • Added export PATH=$PATH:/usr/local/mysql/bin to the buildbot virtualenv bin/activate file
  4. Tested the buildapi/buildbot dev setup I have works end-to-end. It is unclear if buildbot is actually grabbing the new build requests and pending them. I need to check with Armen on this… It is unclear where exactly to look for these pending builds via buildbot. I have found that once entering a build_request that the new request instantly shows up under the same branch it was requested under pending jobs for the day today. i.e. I rebuild a job from July 10th, and then I go back to view jobs for today at a link like and it has shown up in the pending jobs section. I tested with buildbot shut down and it still worked… so I am still unclear how to check that buildbot likes or dislikes a build_request
  5. Edited/Modified the manual unit tests for the patch
  6. Started writing the patch for bug 793989

    1. Took some time to get reacclimated to the exact issue and which db tables need to be filled
    2. Unclear on a couple of points, also going to clarify with coop/armen on Monday

More next week! Have a great weekend!

Tagged with:
Posted in Mozilla

Buildbot is up and running!

Buildbot is now up and running on my local Mac! :)

Picking up from where I left off in my previous post, this is what was necessary to make this happen:

  1. Firstly, attempting to run 'make checkconfig' from ~/Buildbot/buildbot/ was completely misguided. I was under the impression that the master/ directory that I was looking for was ~/Buildbot/buildbot/master/. However, this was incorrect as the true master directory I needed was ~/Buildbot/build-master/.
  2. cd BASEDIR/build-master/
  3. Modify line 2 of Makefile from BUILDBOT=$(PWD)/bin/buildbot to be BUILDBOT=$(PWD)/../bin/buildbot
  4. make check-config

    • This fails with the Traceback:
    • (Buildbot)localhost:build-master jzeller$ make checkconfig
      cd master && /Users/jzeller/Buildbot/build-master/../bin/buildbot  checkconfig
      Traceback (most recent call last):
        File "/Users/jzeller/Buildbot/lib/python2.6/site-packages/buildbot-0.8.2-py2.6.egg/buildbot/scripts/", line 1042, in doCheckConfig
        File "/Users/jzeller/Buildbot/lib/python2.6/site-packages/buildbot-0.8.2-py2.6.egg/buildbot/scripts/", line 31, in __init__
          self.loadConfig(configFile, check_synchronously_only=True)
        File "/Users/jzeller/Buildbot/lib/python2.6/site-packages/buildbot-0.8.2-py2.6.egg/buildbot/", line 652, in loadConfig
          exec f in localDict
        File "/Users/jzeller/Buildbot/build-master/master.cfg", line 129, in <module>
          execfile(releaseConfigFile, releaseBranchConfig, releaseBranchConfig)
      IOError: [Errno 2] No such file or directory: ''
      make: *** [checkconfig] Error 1

  5. Modify line 11 of master_config.json so that 'release_branches' contains an empty list. It did contain ["mozilla-1.9.2",  "mozilla-beta"] and they are unnecessary for my local setup.

  6. Again: make checkconfig

    • SUCCESS: Config file is good!

  7. make start

    • It will appear as if start has failed, but fear not! You'll see the message below, but this is simply because the buildbot process is launched as a dameon and buildmaster waits to give the all configuration is complete signal. However, Mozilla's configuration files are way to complicated to be dealt with in under 10 seconds, so it times out and you see the message below:

    • (Buildbot)localhost:build-master jzeller$ make start
      cd master && /Users/jzeller/Buildbot/build-master/../bin/buildbot  start $PWD
      Following twistd.log until startup finished..
      2014-01-22 14:47:30-0800 [-] Log opened.
      2014-01-22 14:47:30-0800 [-] twistd 12.0.0 (/Users/jzeller/Buildbot/bin/python 2.6.7) starting up.
      2014-01-22 14:47:30-0800 [-] reactor class: twisted.internet.selectreactor.SelectReactor.
      2014-01-22 14:47:30-0800 [-] monkeypatch_twisted_cbLogin applied
      2014-01-22 14:47:30-0800 [-] Creating BuildMaster — buildbot.version: 0.8.2
      2014-01-22 14:47:30-0800 [-] loading configuration from /Users/jzeller/Buildbot/build-master/master.cfg
      2014-01-22 14:47:30-0800 [-] unable to import dnotify, so Maildir will use polling instead
      2014-01-22 14:47:30-0800 [-] nextAWSSlave: start
      2014-01-22 14:47:30-0800 [-] nextAWSSlave: start
      2014-01-22 14:47:37-0800 [-] nextAWSSlave: start
      2014-01-22 14:47:37-0800 [-] nextAWSSlave: start

      The buildmaster took more than 10 seconds to start, so we were unable to
      confirm that it started correctly. Please 'tail twistd.log' and look for a
      line that says 'configuration update complete' to verify correct startup.

      make: *** [start] Error 1

  8. To doublecheck that the configuration was successful, just follow the directions and type: less twistd.log | grep "configuration update complete". As long as you see it pop up then you're good!

  9. Go to http://localhost:8501/

  10. If you a page with "Welcome to the Buildbot for the Firefox project!" then you have been successful!

  11. You can now check out what buildbot has pending by going to http://localhost:8501/waterfall

Now buildbot is all setup! Hooray!

The next steps are:

  1. Update all the documentation to reflect this new found path!
  2. Update and upload the scripts that can make this process much easier, a buildbot-on-laptop if you will
  3. Run a database dump on my personal schedulerdb and statusdb that represents a smaller subset of builds/tests… Ideally something small enough to send around to others.

    • Send this to Armen for his BuildAPI setup
  4. Replace my current schedulerdb and statusdb with these smaller subsets to claim back more harddrive space – currently 100gb+!
  5. Backup new schedulerdb and statusdb
  6. Link up buildbot to the proper database
  7. Test that running an existing command from BuildAPI has the expected results in buildbot by looking at the http://localhost:8501/waterfall UI
  8. Finish writing up all of the manual unit tests that need to be used for testing Bug 793989's patch
  9. Modify BuildAPI to add the new functionality for a Bug 793989 patch
  10. Test/Review the patch!

Here's to shipping this patch!

Tagged with: , ,
Posted in Mozilla

Setting Up a Development Master

Setting up buildbot on my local Mac has proved to be more difficult than I first realized. hwine has helped me out by modifying and sharing a script that helps to setup a new buildbot project called, and combining that with the create-staging-master script that can be found on the How To Setup a Personal Development Master, I think buildbot will be all setup on in my local dev environment pretty soon! However, I have run into some issues, which I already emailed hwine about, but I will rephrase them here.

Here is how I set things up, complete with how I fixed a few issues:
  1. Downloaded and create-staging-master to ~/
  2.  ./ Buildbot
  3. cd Buildbot; source bin/activate
  4. cd buildbot-configs; ./

    • All tests passed
  5. cd ~
  6. Modify create-staging-master so that "my $basedir = '/builds/buildbot';" becomes "my $basedir = '/Users';" on line 39
  7. sudo perl create-staging-master –username=jzeller –master-kind=build –config-only

    • This creates a new directory at ~/build1 which contains config.json

      • More on this below, but I think the config.json file needs to be at ~/Buildbot/buildbot instead. However, when you run the script with the parameter –master-dir set to either Buildbot/ or Buildbot/buildbot, it complains that the directory already exists.
  8. Now that I want to see if it all works, I am trying to follow the Does It Work? section in the How To Setup a Personal Development Master wiki.
  9. cd $BASEDIR/master; ln -sf ../buildbot-configs/mozilla/universal_master_sqlite.cfg; cd -

    • Since $BASEDIR is not set by the 2 scripts you sent over, and the script in the Create a Build Master section sets it to /builds/buildbot/$USERNAME/build1, I go ahead and set it to BASEDIR=/Users/jzeller/Buildbot/buildbot
  10. Again: cd $BASEDIR/master; ln -sf ../buildbot-configs/mozilla/universal_master_sqlite.cfg; cd -

    • Successful… tried with BASEDIR=/Users/jzeller/Buildbot/ and it failed because there was no master directory in ~/Buildbot
  11. make checkconfig

    • When attempting from ~/Buildbot/buildbot, this fails with: make: *** No rule to make target `checkconfig'.  Stop.
    • After speaking with aki (check scrollback on mozbuild), it seems as though the Makefile I had in ~/Buildbot/buildbot was just dev utils
    • aki pointed me to the Makefile.master in buildbot-configs and I cp'd it to ~/Buildbot/buildbot and modified BUILDBOT=$(PWD)/bin/buildbot to be BUILDBOT=$(PWD)/../bin/buildbot
  12. Again: make checkconfig

    • Fails in a different way:

      • (Buildbot)localhost:buildbot jzeller$ make checkconfig
        cd master && /Users/jzeller/Buildbot/buildbot/../bin/buildbot checkconfig
        Traceback (most recent call last):
          File "/Users/jzeller/Buildbot/lib/python2.6/site-packages/buildbot-0.8.2-py2.6.egg/buildbot/scripts/", line 1042, in doCheckConfig
          File "/Users/jzeller/Buildbot/lib/python2.6/site-packages/buildbot-0.8.2-py2.6.egg/buildbot/scripts/", line 18, in __init__
            copy(configFileName, tempdir)
          File "/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/", line 84, in copy
            copyfile(src, dst)
          File "/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/", line 50, in copyfile
            with open(src, 'rb') as fsrc:
        IOError: [Errno 2] No such file or directory: '/Users/jzeller/Buildbot/buildbot/master/master.cfg'
        make: *** [checkconfig] Error 1
    • I realized that the master.cfg found in ~/Buildbot/buildbot may be a faulty sym link, so I modified the command from step 10 and reran it with an absolute path: cd $BASEDIR/master; ln -sf /Users/jzeller/Buildbot/buildbot-configs/mozilla/universal_master_sqlite.cfg; cd -

      • This gets the same Traceback as above

I am stuck at the make checkconfig step here, SO CLOSE. Here are a few other questions off the bat:

  • config.json surely goes somewhere within the Buildbot base directory, but I am not sure where this would be appropriate. I attempted to set the –master-dir parameter to either Buildbot/ or Buildbot/buildbot, it complains that the directory already exists.
  • aki is saying that I may have an easier time recreating the master, rather than modifying configs, however I am not sure how that relates to using these 2 scripts, and create-staging-master in tandum.

So for the moment this is where I am stuck, and I will be attempting to tackle this more on Friday.

Tagged with: ,
Posted in Mozilla

Happy New Year!

Happy New Year everyone! Now that it is 2014, it is time to get back up to speed. Here is where I am at currently, ie as of mid-December

  • We decided to go ahead and manually test the patch needed for bug 793989, since it is needed in semi-short order. After the patch is of a fairly decent 1st iteration, then we will go back and diagnose the nosetests issue and determine how to restore our unit testing ability with pylons. This is extra important given that more and more people are becoming interested in BuildAPI and so we need the stability that comes with a solid testing framework.
  • I met with Armen last year and we are going to be working side-by-side on tackling the rest of this patch, he pointed me to his blog post on setting up a local buidbot instance so that I can use it for testing my patch.

Here is what I have in front of me now

  • Setup a running buildbot master instance on my local machine and verify that it can receive and "start" jobs from BuildAPI commands already present in the UI
  • Document the necessary manual unit tests needed for this patch in the wiki
  • Write up the additions to catlees patch necessary to get us to phase 1, which should include the ability to make an http POST request with the necessary parameters and having that launch an individual test on buildbot specified by those parameters in the POST request.

More updates to come as this list of things is knocked out.

Posted in Mozilla

About Me

The more I write software, the more I realize what drives me and sustains my interest in this profession; and it's the people. Writing software someone is going to directly benefit from is as exciting as any job that I can think of. My goals are to work with a company that isn't just holding the line, but is pushing the edge of what is out there. I seek to make an impact on my community and my planet, in a positive and uplifting way through the power of software.