Confirmed users
313
edits
Auto-tools/Projects/Autoland: Difference between revisions
→Autoland: Restructure page to make sense with Q1 objectives
(→Milestone 1: Update with work accomplished in 2014Q4) |
(→Autoland: Restructure page to make sense with Q1 objectives) |
||
| Line 2: | Line 2: | ||
== Introduction == | == Introduction == | ||
Autoland is the name of a project which will enable automatic landing of changesets after a successful try run. | Autoland is the name of a project which will enable automatic landing of changesets to mozilla trees, for instance from a MozReview repository to try or to mozilla-inbound after a successful try run. This will allow developers to land changesets "automatically", with many fewer manual steps than are now required. | ||
== History == | == History == | ||
| Line 11: | Line 11: | ||
* [[BMO/AutoLand]] | * [[BMO/AutoLand]] | ||
* [[ReleaseEngineering:Autoland]] and related [https://github.com/rail/build-autoland/ github repo] | * [[ReleaseEngineering:Autoland]] and related [https://github.com/rail/build-autoland/ github repo] | ||
In Q4 of 2014, a prototype system was built with the goal of automatically landing changes from try to mozilla-inbound after a successful try run. It used pulse to monitor try runs pushed with a special syntax. Failed jobs were retriggered to determine if the failure was due to an intermittent or not. If successful, the transplant service under development by RelEng was used to transplant the results from try to another repository. | |||
== Non-goals == | == Non-goals == | ||
| Line 16: | Line 18: | ||
* This version of Autoland will be designed to work against trunk branches, and will not be designed to assist in uplifting changesets. Future versions of Autoland may add that capability. | * This version of Autoland will be designed to work against trunk branches, and will not be designed to assist in uplifting changesets. Future versions of Autoland may add that capability. | ||
== | == Workflow == | ||
== | == Components == | ||
=== Autoland Service [owner: dminor] === | |||
This is the primary component of Autoland. This service monitors pulse for autoland jobs submitted to try, monitors such try jobs for completion using the buildapi, queries the buildapi for job status, and retriggers failing jobs. The project repo is located at [1]. | |||
It also submits comments to Bugzilla when the Autoland status of a try push changes, and lands patches on inbound trees if all success criteria are met. Patches will be landed using the transplant tool [2]. | |||
[1] https://github.com/dminor/autoland | |||
[2] https://github.com/laggyluke/transplant | |||
=== Treeherder [owner: dminor] === | |||
Treeherder will be utilized in the following ways: | |||
# Treeherder will expose a special Autoland view of try jobs which need sheriff attention; this view will include a button (available only to privileged users) that will allow a pending Autoland push to be landed or rejected. | |||
See {{bug|1058864}} | |||
=== Releng Buildapi === | |||
This api (which exists already) will be used to determine when Autoland try jobs are finished, and will be used to retrigger failing jobs. | |||
docs: [[ReleaseEngineering/Applications/BuildAPI]] | |||
== Roadmap == | |||
=== Milestone 2 === | === Milestone 2 === | ||
Integration with MozReview to enable landing of patches from MozReview to Try from within MozReview with monitoring and reporting of results | |||
target delivery date: 2015Q1 | |||
<bugzilla> | <bugzilla> | ||
| Line 61: | Line 61: | ||
</bugzilla> | </bugzilla> | ||
=== | === Milestone 1 === | ||
A prototype which can be tested end-to-end by pushing to try with a specific syntax. | |||
target delivery date: 2014Q4 | |||
= | status: We deployed an initial version of Autoland that is able to listen to try pushes and utilize the RelEng Transplant tool to transplant successful try pushes from Try to a clone of mozilla-central hosted on a staging instance of the Transplant tool. Transplant is still under active development and is not ready to be deployed, which necessitated testing against a staging instance and a lcocal clone of mozilla-central. | ||
When pushing autoland patches to try it is necessary that the head patch be empty and that the commit message contains the try syntax along with the string '--autoland'. | |||
An example of a summary for an autoland push is: | |||
try: -b do -p all -u all -t none --autoland | |||
Bug XXXXXX - Do interesting stuff; r=yyy | |||
The autoland tool does not mandate a minimal set of tests for a change or check that the patch has been properly reviewed. In order to keep autoland as simple as possible it is assumed that these policies will be enforced elsewhere, for instance, in Mozreview. A check is done to verify that the person who pushed to try is a member of the appropriate LDAP group to land on the destination repository, i.e. scm level 3 in order to land on mozilla-inbound. | |||
A single failure is allowed for each build and test. In this case, autoland automatically retriggers the job to see if it will succeed on the second attempt. If it succeeds on the second run, it is assumed that the failure was intermittent and that the patch can be landed. If two failures occur for any build or test, the autoland request fails. | |||
If the autoland request succeeds, the transplant tool is used to land the changes. Whether or not the request succeeds, the bugzilla bug corresponding to the request is updated. | |||
The proposed workflow for Autoland is as follows: | The proposed workflow for Autoland is as follows: | ||
| Line 105: | Line 109: | ||
6b - If not ok to land, Autoland notifies the developer of the problem via bugzilla. | 6b - If not ok to land, Autoland notifies the developer of the problem via bugzilla. | ||
== | == Bugs == | ||
Bugs should be filed in Bugzilla under Tree Management:Autoland. | |||
<bugzilla> | |||
{ | |||
"quicksearch": "status:new,assigned,reopened,unconfirmed", | |||
"product": "Tree Management", | |||
"component": "Autoland" | |||
} | |||
</bugzilla> | |||