Major Highlights:

  • Kim enabled c3.xlarge slaves for selected b2g tests - bug 1031083
  • Catlee added pvtbuilds to list of things that pass through proxxy
  • Coop implemented the ability to enable/disable a slave directly from slave health

Completed work (resolution is 'FIXED'):

Major Highlights:

  • armv6 builds and tests are disabled
  • ec2 instances avail of a proxy server that stores local cache of ftp downloadables
  • runner, service that runs startup tasks so we don't need to reboot after every job, enabled for centos machines.
  • desktop builders for mac and windows join linux on cedar as they are run via mach and mozharness

Completed Work (marked as resolved):

In First Assignment, I touched on how Mozharness can have multiple configs. You can specify on any script say:

./scripts/some_script --cfg path/to/config1 --cfg path/to/config2 [etc..]

The way this works is pretty simple, we look for those configs and see if it is a URL or a local path. We then validate that they exist. Finally, we update what ultimately becomes self.config by calling .update() on self.config with each config given (in order!).

This is nice and allows for some powerful configuration driven scripts. However, while porting desktop builds from Buildbot to Mozharness

Before I begin to dive in to why it's awesome working on the Mozilla Releng team, what it is we do, or even how we do it, I want to discuss a bit about my role and what I've been up to.

Mozharness All The Things!

Currently we have a bunch of logic about how we 'build' and check the integrity of the steps related to compiling and building firefox. This varies across all our platforms, platform versions, release branches, project branches, and a number of other special types of builds

what is a build?

Taking a look at TBPL