BugzillaAutoLanding: Difference between revisions

Jump to navigation Jump to search

BugzillaAutoLanding (view source)

Revision as of 18:33, 13 January 2012

409 bytes removed ,  13 January 2012
→‎Component Descriptions and Implementation Notes
Line 247: Line 247:


==Component Descriptions and Implementation Notes==
==Component Descriptions and Implementation Notes==
===BugzillaEventTrigger===
===AutolandQueue===
A polling script that will pull all bugs from bugzilla with whiteboard tags matching:
A polling script that will pull all bugs from bugzilla with whiteboard tags matching:
[autoland-$branch]
[autoland-$branch]
[autoland-$branch:$patchID:$patchID]
[autoland-$branch:$patchID:$patchID]


Default behaviour would be to take [autoland-$branch] and grab all non-obsolete, non r- patches into the patchset that is then pushed to $branch, results returned and analyzed for further actions (like try->mozilla-{central,inbound}).  To override or search for regressions we support adding explicit patchIDs to create a custom patchset for an autoland run.
Default behaviour would be to take [autoland-$branch] and grab all non-obsolete, non r- patches and create a patchset db object that is then picked out of the queue to be sent to hgpusher for landing on $branch, results are returned from hgpusher to the AutolandQueue module and analyzed for further actions (like try->mozilla-{central,inbound}).  To override or search for regressions the API will support directly inserting a patchset to create a custom autoland run.
 
In a discussion with Mconnor, the suggestion for user interaction with autoland is to have radio buttons by each attachment (with a bit of select all/none js) so that you could pick your patches for autoland and have an input field & submit button to send something like:
[autoland-try:1234:2345:3456] (greasemonkey script for picking patches)
[autoland-mozilla-inbound:1234]
to the queue which would signify the final push destination and the attachment ids to use for the patch set. Whether this is something we can do with Bugzilla would need investigating so at first we are implementing this with whiteboard tags & polling with the bugzilla API for these tags.


===HgPusher===
===HgPusher===
Accepts a branch, patch id(s) and can clone the branch, apply the patches and report back with results of push (success == revision or FAIL).  Also can handle special casing to do a backout on a branch.
Listens for messages that specify a branch push is requested. Accepts a branch, patch id(s) and can clone the branch, apply the patches and report back to the AutolandQueue via message the results of the push (success == revision or FAIL).   
* Input(s): Bugzilla Messages, command line
* Input(s): AutolandQueue Messages, command line
* Output(s): BugCommenter, hg.mozilla.org, AutolandDB, stdout
* Output(s): hg.mozilla.org, AutolandQueue Messages, stdout


===SchedulerDBPoller===
===SchedulerDBPoller===
Regularly polls the scheduler DB (on a timer) and checks for completed buildruns for any actively monitored branches.  There should be a list to check against for what branches need to be watched. The incomplete runs from the last N units of time are kept by revision in a local cache file to check for completion.  When an observed branch has a completed buildrun the SchedulerDBPoller can check two things:
Regularly polls the scheduler DB (cronjob) and checks for completed buildruns for any actively monitored branches.  There should be a list to check against for what branches need to be watched. The incomplete runs from the last N units of time are kept by revision in a local cache file to check for completion.  When an observed branch has a completed buildrun the SchedulerDBPoller can check two things:
* if try syntax is present (and branch is try) check for a --post-to-bug flag and trigger BugCommenter if flag and bug number(s) are present
* if a --post-to-bugzilla flag is present and a bug number is provided following that flag, then the revision will be kept in a local cache and watched until completion (or time out), when done a bug comment will be posted and a message sent out that this revision is complete in case AutolandQueue is interested in that revision
* run that revision against the AutolandDB to see if that revision was triggered by landing automation.  If yes, then PUT the results & trigger the BugCommenter otherwise ditch the completed revision


* Input(s): command line, AutolandDB
* Input(s): command line
* Output(s): BugCommenter, stdout
* Output(s): AutolandQueue, stdout


===BugCommenter===
===Bugzilla Autolanding Extension===
When called with a bug number and a comment, posts to the bug and returns the commentID as well as a result (SUCCESS/FAIL) -- should handle a few retries in case of network issues -- write to a log file that is watched by Nagios?
In a discussion with Mconnor, the suggestion for user interaction with AutolandQueue is to have radio buttons by each attachment (with a bit of select all/none js) so that you could pick your patches for autolanding and have an input field & submit button to send something like:
* Input(s): HgPusher, SchedulerDBPoller
[autoland-try:1234:2345:3456] (greasemonkey script for picking patches)
* Output(s): Bugzilla, stdout
[autoland-mozilla-inbound:1234]
to the queue which would signify the final push destination and the attachment ids to use for the patch set. Whether this is something we can do with Bugzilla would need investigating so at first we are implementing this with whiteboard tags & polling with the bugzilla API for these tags.


Note: Let's have a couple of template options here for what is posted to the bug depending on if it's a branch or try
We have initiated discussion with the owners of the Bugzilla module about creating an extension that users could enable on their bugzilla account to be able to use a UI similar to what is described above.


===MessageQueue===
===MessageQueue===
'''To-Do''' - Read up on [http://www.rabbitmq.com/ RabbitMQ] and [http://en.wikipedia.org/wiki/Message_queue Message Queue]
This is a util that manages the creation of message queues and routing used by the Autolanding system. It ensures that the right modules receive the right messages.
Listens to messages from BugzillaScraper (or Pulse Events?) broadcasts information to HgPusher, BugCommenter, AutolandDB
* Goal here would be to integrate with existing RMQ in build infrastructure, be able to deploy the components on any masters in the build network to share load and for them to be able to send/receive messages via RMQ to see an autoland cycle through to completion


===AutolandDB===
===AutolandDB===
Keep track of the state of an autoland-triggered push from start to finish.
Keeps track of the state of an autoland-triggered push from start to finish.


===LDAPTool===
===LDAPTool===
Lsblakk
Confirmed users
4,467

edits

Retrieved from "https://wiki.mozilla.org/Special:MobileDiff/386940"

Navigation menu