Tag: releng

Autolanding your patch(es) to Try via Bugzilla

We’re ready for a soft release of the first step in our very experimental autolanding system. Experimental meaning: we reserve the right to pull the plug, take it down for tweaks, and some information may be lost when bugs arise.  You can check the if the autoland system is up and running by going to http://bit.ly/autoland_status

This is the Try branch only portion of what will become a system to automate and more easily manage multiple branch landings.  Marc Jessome, our returning Release Engineering intern, and myself have this as a Q1 goal.  There are several issues to be resolved with this system and the link above will keep you appraised of what the goals and known issues are. We will be working hard over the next two months to make this a secure, reliable system for landing patches with minimal developer time spent pulling, pushing, and watching tbpl.  The hope is that it will also become a useful tool for Release Coordinators to track that a fix lands across several branches as needed.  Future features will include a bugzilla extension to securely interact with this system and remove the need for whiteboard tag changes and a RESTful API so the whole process could be initiated through the command line.  We appreciate constructive feedback but please hold off on scope creep suggestions 🙂 

Here’s how it works right now:

  1. Attach patches to your bug Note: if you (the attacher) do not have permission to push to Try, get an r+ from someone who does
  2. Use this documentation to determine the appropriate whiteboard tag and enter it in the bug so our autolanding poller will pick up on your request
  3. The autoland system, which tracks all bugs with autolanding requests, will queue up your patchset and then pull it from the queue, apply the list of patches in your bug (or those in the whiteboard tag) to a clean pull of mozilla-central tip, commit each patch as the patch author, and finally push to try as Autoland User
  4. A comment will be posted in your bug with the results (hopefully successful) of the push attempt, and the whiteboard tag will read [autoland-in-queue]
  5. After all builds complete, their results get posted back to your bug (just like with the current ‘–post-to-bugzilla Bug #’ flag in trychooser) and the [autoland-in-queue] whiteboard tag will be removed

There is a threshold on how many bugs the autoland system will push and track at a given time.  We are curious to learn about usage and load on this system so please give it a try and inform us of any issues in IRC: #build or #developers channels are the best places to find myself (lsblakk) or Marc (mjessome) and chat us up about this initiative.

Want to help? Encouraging community contributions

In a timely confluence with Mozilla’s new Steward initiative, I’m preparing to get some community contributors engaged with some of the projects we work on in Release Engineering.  A fair amount of our production infrastructure has to be locked behind VPN and sekrit passwords (we have 400+ million users to protect) but there are more and more RelEng side projects. We provide tools to the larger developer community and solve interesting scalability challenges with our unique (and massive) automation systems that can be worked on by any interested person in their own local test environment and then integrated into our /build repos. My personal goal is to try and get 2 or 3 regular community contributors to come work with us on tackling these.

In order to solicit contributions I have been working with David Boswell. We added Release Engineering to the mozilla.org/contribute ‘areas of interest’ page and I have created the beginnings of a RelEng-specific contribution page. The first two areas that I think would be a great introduction to working with RelEng code & tools are the TryChooser and our upcoming Autoland system.  For the latter, our intern Marc Jessome is sticking around this fall as a contributor to carry on the amazing work he put into this system over the summer.  He’ll be continuing to debug the code and improve the portability of it so that we can get it into a beta testing stage by the end of October.  As that work is being done we also need someone to help us write the API functionality that will allow sheriffs and developers to write tools that utilize this new hands-off landing queue.  We’d also be happy to have people work on the issues that come up when we take Autoland to the next level – auto-landing on a production branch.  To do this we’ll want some automated backing out, bisection, and the ability to wait on getting patches reviewed before continuing.

Another great area for someone interested in helping out Firefox developers is working on the TryChooser syntax and features.  There is a whole tracking bug dedicated to try_enhancements and most of those bugs are ones that can be worked on in a local staging environment.  It’s a chance to get your feet wet with buildbot and our custom scheduling setup. Some of these smaller bugs would be short on time commitment and high on developer appreciation if you fix them. That can be a winning combination for a new contributor, I speak from experience on that 🙂

So, if you’re reading this post and you or someone you know is interested in dipping their toes into becoming a Mozilla contributor and these projects make you curious then come find me and we’ll get you set up with a staging environment so that you can start fixing real world tools and automation bugs in no time.