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.
The first step was to write a python script that spawn multiple instances of the bitten slave. The script spawns one instance of bitten for each core the system has. Each instance is spawned in a child process with a unique port number stored as an environment variable. This will be important shortly for queuing up test jobs.
I then worked on writing a bitten recipe that simply calls a local python script, and passes it command line arguments. The location of the local script that the recipe launches, is determined when the recipe is run. The local path to the script is passed by the bitten slave (in the bitten slave configuration file) to the bitten server at connection time. When it connects the bitten server, it tells the server the local path to the script it should run allowing the script to sit anywhere locally and the server to delegate tests to it without the server knowing where the script sits locally.
The next step was to write the script the recipe would call. The script sits on the local machine (which runs the bitten slave as well). It gets called with some set of command lines arguments determined by the recipe but it gets called as a sub process of the bitten client requesting the build configuration (ie requesting the test recipe) from the server.
The script can now spawn a new instance of GraspIt and tell it to listen for commands on a specific port (based on the environment variable that was set when the bitten slave was originally spawned). The script can then use the command line arguments passed by the recipe to run specific tests on GraspIt by sending these tests to the GraspIt socket listening on the designated port.
From here I started working on a way to generate the recipes in batch format. Since the idea was to use each recipe to run a single test or a single set of tests, we wanted to be able to create many recipes with slightly changed parameters very easily and quickly. The first step was to take the recipe I had made originally and parametrize it so that many recipes could be generated from a set of parameters. The first version of this program simply spat out a file with many recipes in it one after the other. We had hoped bitten had a way of easily adding recipes using a batch upload or something of the kind. Unfortunately we found no such thing so the next task was to create a method to add recipes to the system in bulk.
The solution was to use the general recipe addition methods (a set of web based forms) but in an automated fashion. To do this I would write a python script using the mechanize library that would automate both the process of generating the recipe given some set of parameters, and adding it to a new build configuration on the bitten server.
From reading the mechanize documentation and tutorials online you quickly see what a great tool it is. The first obstacle was getting the authentication process to properly recognize my script. Since Trac and bitten don't use forms on pages for login and rather use basic authentication (or in some cases digest authentication) pointing mechanize directly to the admin page doesn't work. Instead you must load your user name and password into mechanize, point it to the login page, and the redirect to the admin page. If you aren't logged in, attempting to load the admin page directly will return a 404 error, not prompt you to log in.
After getting the log in process to work properly, creating a new build configuration (to hold a recipe) is fairly straight forward. Adding the recipe to the build configuration on the other hand is unfortunately not. Mechanize doesn't play so nicely with the way the form is laid out in bitten. The default submit button is the cancel button and getting the form to submit with the save button seems to be an issue many people have dealt with with other applications.
See: http://stackoverflow.com/questions/734893/python-mechanize-two-buttons-of-type-submitNext week starts out by trying to find a solution.
0 comments:
Post a Comment