I’ve been busily working on Cerberus this week, mainly working on the website that acts as the front-end to the system. The entire front-end uses files rather than a database to store the data, I was considering using a database, MySQL or similar, but I really like the idea of the entire build system existing under a single folder, so it’s simple to backup and move around.

This is the main screen for the Cerberus front-end, it contains a list of all the repositories that Cerberus knows about, each repository also list its’ URL, and if it has been built, a summary of the report from the most recent build (clicking on the summary will take you to the full build). Also there is buttons to build each repository, which are now blue (previously they were green) due t the need to add an ‘Add Repository’ button below the list that should be green.

This screen shows the detail of a single report, with error and warning logs for each operating system, and also shows the amount of time it took to compile for that platform.

Here is the list of reports for all the repositories, the reports are listed in time/date order, with the most recent at the top. Each of the reports also shows it’s summary, which is the total number of errors and warnings that occurred during that build.

This screen shows the status of all the build slaves, most prominent is the operating system that the slave is running on, it also shows the IP and port they are listening on. (I was hoping to show more than one build slave active, however for some reason when I came to take the screenshots this morning both the build slaves were managing to be reporting themselves bound to the same port, which caused only one build slave to show up on this screen).

Not so much left to do with the front-end now, need to add the ability to add/remove repositories, and then finally hook up the build button and then it’s back into the internals to make the build process as solid as possible and report errors in a meaningful way. It’s still a fun project to work on and I’m looking forward to having it working hopefully sometime soon.

As you may or may not know, LibCT version 1 was created as part of the Middleware module for the final year of my university course. The had two assignments, the first has us making a piece of middleware that would aid people making games, the second saw us making a game which integrated as much middleware as possible. LibCT was used the majority of my classmates games (helped by the fact that it took about 5 lines of code to get working).

The same module is being run this year and again students have been making games with all the middleware they could find, which for one student Justin Alexander included LibCT (now on version 2). There was some issues setting it up (mainly due to LibCT being developed on Visual Studio 2010 but Justins’ project being built in Visual Studio 2008) but he got it working and apparently found the editor very easy to use (which is what I was going for).

When the prject was done he was kind enough to send me a link to the video he made to demonstrate the game which also shows off LibCT rather well, check it out:

Rather ingeniously the LibCT event system is used to trigger the text-to-speech recordings which really add an extra level of polish to what is already a very good game (especially considering the tight deadlines) .

Justin will by now be pretty much finished with uni, and I wish him luck as he embarks on what I reckon will be a bright career making games!

 

So I have been continuing to work on Cerberus, mainly focusing on getting CerryPy and Jijna2 working together to provide the web interface (which seems to be working nicely). I also fired up Photoshop to craft a layout of what this web-interface will look like:

I wanted to go for a clean ‘app-like’ look with a nice amount of spacing and after several hours of staring at it I still liked it so I started cutting it up and got to work laying down the HTML (5, obviously) and CSS to make a site which replicated this image.

Other than that I’ve been setting up the virtual machines (VirtualBox is such a nice piece of software to use) which posed an interesting problem.

Virtual machines (referred to as guests) do not have direct access to the network interfaces of the host machine, instead the guests (by default, this can be changed) connect to a software router provided by VirtualBox which allows the guest OS to do such things as access the internet however, a process on the host machine will be unable to contact a process on the guest machine, which is obviously an issue as the build_master will be running on the host machine and some of the build_slaves will be running on the guest machines.

Now, it is possible to configure VirtualBox to forward certain ports to certain guest machines, which will allow a process on the host machine to talk to a process on the guest machine and visa-versa, however, this then runs into the issue that effectively these processes will be running on the same machine, and thus cannot bind their TCP server sockets to the same port. This issue can be handled, an attempt to bind a socket to a port that is already bound will result in an exception that can be caught, and allow us to try another port until we find one we can use.

This results in a different issue, now we have n build_slaves, each running on a different port and we don’t really know which ports they are listening on, making contacting them rather difficult. The solution to this is a system I have implemented a few times before. The build_master fires up a UDP port that is listening for broadcasts, build_slaves broadcast messages to that port stating the IP and port the TCP server is listening on and also the operating system they’re running on, the build_master maintains a list of ‘active’ build_slaves (a build_slave is considered active if the build_master has received a broadcast message from them in the last 60 seconds. Now when the build_master receives a command to build a repository it simply communicates that to all the build_slaves in it’s active list.

So that’s my progress so far, I hope to have time this weekend to get the web-interface up and running so that I can trigger a build directly from that, again I’ll report on progress when there is some.

I recently got my shiny new laptop (from PCSpecialist, would definitely recommended them) which has now replaced my long suffering former laptop as my main development machine. This leaves me with a ‘spare’, decently powerful laptop which is perfect for a project that I have been wanting to do for a while now: Create a 1-click build machine.

Basically I want a system that allows me, with a single click, to trigger a script (or scripts) that will clone/update a Mercurial repo, execute the Premake script to generate the solution/project/makefiles, compile the project run a post build step (unit-tests or the like) gather all the information (warnings/errors/compilation time) and stick it in a nice web-page for my viewing. Also this needs to run on Windows, Linux and OSX, running on the same machine (natively running Linux, with Windows and OSX virtual machines).

Sounds like a fun project right? And I really like the idea that in one click I can know that my code compiles on all the major operating systems (and that I’ve not forgotten to commit any needed files). Also I decided to make this system in Python, since I’ve been meaning to learn it and nothing helps me to learn a language more than making a project in it.

So, I hear-by present, Cerberus:

cerberus.py

This is the python code that acts as the server and the main point of entry to the system, you will be able to access this from a browser and see the build reports and trigger new builds, as-well as taking care of other admin stuff.

build_master.py

This script, called by cerberus.py is responsible for triggering the builds across all platforms, it then collates the result of these, makes a pretty report out of it, and saves it as a timestamped html file that can be accessed by cerberus.py

build_slave.py

This script is a permanently running TCP server, waiting for build_master.py to contact it with the url of a repository. (Note that initially there will only be the option to build, in the future there may be other commands these scripts can execute.) It is responsible for cloning/updating the local repo and reports the results of the build command back to build_master.py

build_slave_[linux|osx|windows].py

These scripts contain the platform specific code to actually generate and build the projects and parse the output from the compiler into a standard format which is passed back up to build_slave.py

 

This is the plan anyway, I’m not sure if it will work, I’ve not looked at other build systems, I’ve never touched Python before and I don’t actually know if I can get OSX to run on my laptop, but it’s going to be fun finding out.  I shall post my results when there is any.