The Zend Framework now includes integration with the Dojo Javascript library, so it was a natural decision to try and work with the two systems to try and make my latest project functional and look good too.

Unfortunately, this turned out to be too time consuming to make the UI look and act the same in both Firefox and IE. Most of the time, complex nesting of Dojo elements have very different renderings in the two browsers.

So, my next choice for adding Javascript visual effects is YUI. So far I’ve had a pretty good experience with the library, and it works with JSON data types as well, so I can reuse a lot of my data generation code that I was using with Dojo.

I’ve decided that I’d like to try to build a module for the Zend Framework to include the YUI library, and integrate it with Zend Forms, the same way that Zend Framework integrates Dojo.

For starters, I’m just going to be creating some decorators to incorperate the YUI calendar into the Zend Form, and maybe the WSYWIG editor as well.

If you’re interested in helping, then by all means, leave a comment and let me know…

The main page for the Try Server is up now, with much more work to do later. The Login and Register links will work when I have the login and register system written.

Right now, there is two build slaves running on a linux VM, and one mac slave running on seneca’s xserve.

Once the other slaves are up and running, then we’ll be adding in some testing into the picture (hopefully).

Want a link? Sure you do. http://hera.seneca.on.ca/tryserver/

You can see the buildbot waterfall here if you want. Although, right now it’s nothing to write home about.

With this release, I would like to have the Try Server ported over to Seneca’s Hera cluster. This cluster consists of about 10 Windows machines, 5 Linux, and 1 OSX. It’s always important to try and make the releases more usable, so I am also planning on adding in downloadable completed builds.

Also on the plate, some kind of user authentication. This will be used to determine if you can get on the system at all, as well as determining what kind of access rights you have to other features. Some of these features include spawning EC2 instances when our cluster is full, and spawning VM’s with your recent build installed on them  to see how it runs.

Also comming up, if you are following along with Armen’s blog, is the integration of Testing with the Try Server.

Lots to look forward to for next week.

Mozilla currently uses a Try Server to allow developers access to upload, build, and test their patches on all 3 major OS’s. In addition to providing developers access to OS’s they may not have, it also frees up the developer’s machine from having to compile. This whole process probably makes developers with limited hardware extremely happy.

So, Seneca has decided to start up our own Try Server. This is both to provide public access to a Mozilla based Try Server, and to allow room to add EC2 support to the Try Server, without interrupting the flow of Mozilla’s server during testing and initial implementation.

Hopefully this project gets used a lot (I think it will).

We’re in the process of getting some resources lines up as we speak, but there will be a couple machines of each OS available on the cluster. Details to follow when available.

As always, more details are posted on the wiki.

With my project going from 0.4 to 1.0, I’m finding myself at a loss of direction. Not that there aren’t directions to go, just that theres so many directions to take this project.

With Mozilla trying to switch their systems over to using Buildbot, I want to work on something that will be most beneficial to them. So, heres your chance to get free work done on some much needed functionality Mozilla!

One area where I’m looking into is with the Mozilla ‘try’ server, and the idea of ‘build on check-in’.

One thing I’m not sure about is how busy a Mozilla try server would be. If there are large gaps in usage where people are not uploading patches to the try server, then I would think it would be a perfect place to implement some EC2 functionality in there.

Same goes for build on check-in. If there are large gaps in usage, then this would be another good place to look at implementing some EC2 functionality. Also, if the server is busy building already, and a developer really needs their build to start right now, then it’s also possible to look at having that situation trigger an EC2 instance to meet this sudden and “temporary” increase in usage.

I’m not really sure about either of these ideas. I don’t know enough about the entire process of submitting a patch and having it built to come up with any more meaningful ideas.

So, if anyone has any suggestions for me, then that would be awesome.

Since Heather and I named the first one Tortuga (turtle in Spanish), we decided to keep with that theme, and chose Kame (Korean) and Chaara (Japanese).

Here are some pics…

dsc00420.jpg

dsc00431.jpg

dsc00435.jpg

My Goals:

• Use meta-data (also called user-data) to create a build slave at run time
• Create generic startup script for making your own AMI instances
• Build Mozilla on an EC2 instance through Buildbot

So this iteration is basically trying to get my project into the “publically useable” stage. Right now, it’s fairly easy to set up these modifications to use EC2 instances in any Buildbot build project.

To use, you need to have Buildbot installed already. Then, you need to download the BOTO python library from Google, and place the boto folder from that zip file into your build-master directory. Then, you need to extract my patch into your build-master directory. Thats it for system prep.

Then, you need to go to AWS.AMAZON.COM and sign up for an account. When you do that, you will need to get your Public Key, and Secret Key to paste into your build-master’s master.cfg file.

In your build-masters master.cfg file, where you would normally specify your list of BuildSlaves, you will be replacing BuildSlave with EC2BuildSlave. This custom class is what allows Buildbot to start EC2 instances and create slaves to use on them. You need to specify a few extra variables in the slave configuration.

By default, you need to specify:

• Bot Name
• Bot Password
• Public Key
• Private Key
• [IP Address of Build-Master:Port] [Bot Name] [Bot Password]

By supplying the build-master’s IP address to the EC2 slave, you are allowing the build-slave on the EC2 instance to be pointed at your machine. If you have a DNS, then that will work in this place as well.

There is a generic Amazon EC2 instance (also called an AMI) created that is set by default in the EC2BuildSlave class. However, if you desire, you may also insert a custom AMI instance ID to the EC2BuildSlave and have it start up your own AMI. See the custom startup script, in the 0.3 deliverable zip, to insert into your instance to have your build-slave created at run-time.

Thats pretty much it. Enjoy.

Oh, also, here’s some screens of building Firefox Trunk.

It should cover the basics of trying to install it, but I’ve left out instructions for installing Buildbot itself, cause there are already lots of pages describing that setup process.

Anyways, if you’re interested, you can check the link here.

• Build Mozilla using an EC2 Instance
• Complete Documentation
• Generic EC2 instance for Buildbot Slaves
• Startup Scripts for making your own EC2 instances

Basically, I want to make this iteration into something that everyone can use without needing to ask me any questions about anything (although, questions are always welcome). Right now, my EC2 Instance is set up with a static IP address for pointing back to a build master. I need to change this to create a new build slave at startup using the metadata to obtain the buildmaster’s IP address.

Another step, is that I want to create a script that anyone can use in their instance startup, so that you have the ability to create your own custom EC2 instances with this buildbot support plugged into it.

Part of making this project a little easier to use and work with is the documentation. This should all be done, and make it easy to understand how to install everything, and how to make it work for your own projects.

Lastly, the whole point of this project is to get buildbot to build mozilla using EC2. So, instead of just building buildbot, I will change up the config file to build mozilla instead.

   from buildbot.EC2BuildSlave import EC2BuildSlave   c['slaves'] = [EC2BuildSlave("bot1name", "bot1passwd", "public key", "private key", "dns", "instance-id")]

   //Where dns = www.whatever.com:8898, or 88.123.55.456:8898

//and public/private key is your public/private key from Amazon

//and instance-id is the instance you would like to launch ("ami-87d530ee")

How, you might ask, does the DNS for your BuildMaster get sent to the new EC2 instance, and at startup no less?

Well, thanks to Ted (luser) Mielczarek, I now know about EC2 metadata. The DNS is uploaded to the new EC2 instance as a peice of metadata at runtime, which the instance can use in it’s startup scripts to start a BuildSlave pointed right at your machine.

Downloads? Sure, just follow the link.