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:
- 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
- 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
- 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
- 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]
- 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
No comments:
Post a Comment