BMO/AutoLand: Difference between revisions

From MozillaWiki
< BMO
Jump to navigation Jump to search
Line 32: Line 32:
AutoLand.getBugs():
AutoLand.getBugs():
* returns a list of bugs, each being a hash of data needed by the AutoLand polling server
* returns a list of bugs, each being a hash of data needed by the AutoLand polling server
* [ { bug_id => $bug_id1, attachments => [ $attach_id1, $attach_id2 ] }, ... ]
* [ { bug_id => $bug_id1, attachments => [ $attach_id1, $attach_id2 ] }, branches => $branchListFromTextField ... ]
* anything else needed by the server?
* anything else needed by the server? <-- Is it possible to get the user who submitted this request?


AutoLand.landUpdate({ bug_id => $bug_id, attach_id => $attach_id, status => $status, message => $message }):
AutoLand.landUpdate({ bug_id => $bug_id, attach_id => $attach_id, status => $status }):
* Let's BMO know if a patch has landed or not and BMO will update the auto_land table accordingly
* Let's BMO know if a patch has landed or not and BMO will update the auto_land table accordingly
* $status will be a predetermined set of success/error codes.
* $status will be a predetermined set of pending/complete codes -- when pending, the UI for submitting autoland will be locked and once complete status update occurs the UI can be unlocked and this entry can be removed from tracking by WebService API
* $message will be added as a bug comment
 
Bug.comment({ ids => [$bug_id], comment => $comment }) (present):
* Update the bug comments to let the user know of any status updates


=== Database Schema ===
=== Database Schema ===

Revision as of 20:19, 1 February 2012

AutoLand Extension

Overview

Lukas Blakk and Marc Jessome have been working on enabling automatic landing of patches from Bugzilla to the Mozilla code repositories. They are approaching a stage where the feature can be tested in a staging area, so they need some UI changes be implemented in the Bugzilla Tweaks Extension or in BMO directly.

Release Engineering Project Page: Bugzilla Auto Landing

Details

Rather than use Bugzilla Tweaks at all, which we would like to slowly phase out as we add more features to BMO directly, we propose creating a BMO extension called AutoLand. This would allow us to incorporate the needed functionality directly to BMO with the need of add-ons or javascript. Also using an extension, we can create a separate database table allowing us to store data for use by the WebService API calls and other workflow status. This will alleviate the need for using the whiteboard which could be prone to error if the user does not format it correctly or if someone adds to the whiteboard that should not be allowed to.

Use Case:

  1. A user that has patch(es) attached to a bug and wants to have the patch(es) autolanded will check the a checkbox next to each patch in the attachments table, they will enter any branches the patches should be applied to after a successful Try run by entering something like 'mozilla-aurora,mozilla-beta,mozilla-central' into a text box (only present when extension is enabled) and then submit this information to a database via an Autoland submit button.
  2. The current AutoLand polling server, using a WebService API call will look for bugs that have patches AutoLand submitted on that are not yet marked as landed, will look for attachments that need processing.
  3. The AutoLand server will push the patches to try, and if successful, commit to $branches if the autoland initiator has the proper permissions. A message will be sent back to the WebService API to update the status of this entry
  4. The AutoLand server, once the process is completed, uses another WebService API call to update the status of the entry to complete so the autoland input UI can be unlocked for additional use
  5. During each step of the process, try, hg commit, etc., the AutoLand server uses the Buzilla API (using their own tools to interface with it) to add comments to the bug report letting the user know the status of their patch(es).

[missing anything?]

Implementation

show_bug:

  • Add a new hook to the attachments table allowing for an additional column to be displayed containing the AutoLand checkbox for an attachment.
  • When a patch has been checked for AutoLand, disable the checkbox so it cannot be manipulated until the AutoLand server has finished processing the patch.
  • If there is an error with the Autoland process, the server sends a message to BMO and the checkbox becomes unchecked, allowing the user to resubmit if needed.
  • If all is successful, the checkbox remains checked and a new patch must be attached to start the process again. (I don't think this should be the case, someone might want to re-try the same patch with other supplemental patches)

WebService API

AutoLand.getBugs():

  • returns a list of bugs, each being a hash of data needed by the AutoLand polling server
  • [ { bug_id => $bug_id1, attachments => [ $attach_id1, $attach_id2 ] }, branches => $branchListFromTextField ... ]
  • anything else needed by the server? <-- Is it possible to get the user who submitted this request?

AutoLand.landUpdate({ bug_id => $bug_id, attach_id => $attach_id, status => $status }):

  • Let's BMO know if a patch has landed or not and BMO will update the auto_land table accordingly
  • $status will be a predetermined set of pending/complete codes -- when pending, the UI for submitting autoland will be locked and once complete status update occurs the UI can be unlocked and this entry can be removed from tracking by WebService API

Database Schema

auto_land:

  • id INTEGER AUTO_INCREMENT
  • attach_id INTEGER NOT NULL /* Foreign key to attachments.id */
  • who INTEGER NOT NULL /* Foreign key to profiles.userid. The BZ user who requested the autoland (not necessarily patch author) */
  • landed BOOLEAN DEFAULT 0 /* Set to true when the patch has landed */
  • landed_when DATETIME /* Timestamp when the patch landed */