The Good, The Bad, and the Ugly.

Ok, this week has been very busy for me RelEng wise, with some good, bad and ugly stuff.

The Good

  • I upgraded all our Windows slaves for the DirectX SDK, enabling us to ship the redistributable parts of that with our binaries, allowing most of our users to have GPU acceleration just liek in Firefox, where they normally would not have; also enables us to build ANGLE a critical part in that acceleration. — Mostly benefits our trunk/SeaMonkey 2.1 builds.
  • Upgraded our [windows] slaves to HG 1.7.5, enabling me to work on Bug 643324 which enables HG_SHARED support on our Windows Machines. My work there only enabled the use of share for the larger repo’s we have; namely comm-* and mozilla-* and left LDAP/etc. pulled as normal. (mac and linux coming soon). The idea and the basis for this was due to the work Chris Atlee performed on try recently, read his blog post for more information and why this is so good!
  • Spun up the oilspill builds for 2.0.13 [ftp] in line with the upcoming chemspill releases for Firefox 3.5.18. (I have not yet announced these builds yet, but I should have a call for testing up within 24 hours, feel free to jump into it with this blog post though)

The Bad

  • While doing the hg upgrade on our slaves, I created the hgrc’s I needed using the slave-side windows notepad; Forgetting of course, that notepad saves in Unicode by default, including a BOM; which our Hg was unhappy with, breaking some builds. At the same time I did not save some of the |.hgrc| files correctly, and they got windows-translated to |.hgrc.txt|, cleaned that up swiftly.
  • While preparing for the 2.0.13 release, I updated the configuration file locally, but forgot to specify the ssh://* repo url when I went to push, so my local push failed. I did not notice and reconfigured our build master and triggered the buidls anyway. This caused the already-on-ftp 2.0.12 build1 builds to get overwritten along with the support files. And delayed me having 2.0.13 ready sooner.

The Ugly

  • Because of the bad mistake with 2.0.12, I made matters worse. When I went to start to sync in from the pushed-to-release files, I clobbered in the wrong directory on stage (ftp), which meant I cleared the WHOLE build1 dir of SeaMonkey 2.0.12, causing me to miss some intermediate files that are needed by automation (I did lose the crashreporter symbols too, but those are unneeded by our automation at present).
  • Due to clobbering those files, I tried recreating them by hand, after a few hours of re-syncing in the necessary files as they should appear in that folder. I created the BuildID, but sadly, I used the abbreviated buildID (YYYYMMDD) rather than the full one (which varies by OS/Build here). The reason that matters is that the 2.0.13 automation, when generating/verifying the updates writes that build-id as specified on ftp to some files needed for sanity-check automation only and then uses them to download and test updates. So I then had to go back in and update those values correctly, update the config files for that automation step, and re-run.
  • I have not yet managed to have a trouble-free release since I took over, from “GO”->”Release”, here is hoping for next time.

 

This entry was posted in Mozilla. Bookmark the permalink.

One Response to The Good, The Bad, and the Ugly.

  1. Callek says:

    I had to back out the changes to the buildbot master for enabling HG_SHARED, I guess I have more work to do on that front.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>