Day 4

This post may be unfinished. My research has since ended and I decided that the benefits of this blog did not outweigh the time required to continue writing posts. I have decided to post the unfinished posts for continuity's sake.

Today I came in on Friday and worked half a day.
My primary goal was getting the bitten slave to run properly on the virtualized machine.
While I could get the slave to connect to bitten properly, and pull the build recipe from the server, the slave refused to connect properly to the svn repository and continually gave me an authentication error along the lines of

... authorization failed: Could not authenticate to server: rejected Basic challenge ...


Although bitten allows you to pass a username and password to the slave at run time on the command line, this username and password seem to be used specifically by bitten and trac, but not for svn.

The solution: Using a slave configuration file. Slave configuration files sit on the local machine where the slave is running and are passed to the server when the slave connects. They basically give the server information about who the slave is and what configuration it is using (name, operating system etc.) In bitten's own words:

When a build slave registers with a build master, it sends information about the machine the slave is running on, and what software it has available. The build master uses this information for matching the slave against target platform rules. While some of this information can be automatically discovered by the slave, other information may need to be configured explicitly. Also, a slave instance may want to override some of the automatically computed attributes, for example to enable cross-compilation.

How does this help us? Well, you can pass information about anything in the configuration file (as long as it's a short text string that you can put in the .ini file that is the configuration file). Some values passed in the configuration file are automatically used by the build master, such as machine name and operating system. The big benefit though, is that in a bitten build recipe, you can use these passed values to parametrize your recipe. For example if I include the following code in my configuration file:

[foo]
bar= baz


in my recipe I can then refer to this as ${foo.bar} which will be replaced by baz when the recipe is run.

It's clear how useful to us this can be. If we can pass the svn username/password information we want to use, then we can tell the slave to use those details for the check out. This extends beyond just the username/password combination, we can use this to determine the local directory to which we want to save the files checked out the from the repository- especially useful for being compatible on multiple operating systems.

I also worked on writing a script that runs the bitten client on startup and makes sure that the bitten client is running at all times. It's a short python script that checks if the bitten client is listed in the task list, and if not, it runs it. This is linked to a system task that runs every few minutes, every day, thus ensuring the client is always running on this computer.