1089570 - Workflow for auto-landing Release Engineering changes to hg.mozilla.org/build/* repos

Status: RESOLVED WONTFIX

(bugzilla.mozilla.org :: General, defect)

Description

[Pete Moore [:pmoore][:pete]]

When we roll out Release Engineering changes, we attach patches to bugs, wait for them to be r+'d, then manually land the same patch to hg.mozilla.org, and then Build Duty deploys to production, and updates the bugs, to say they have been deployed to production.

We have automated a process for updating the Release Engineering bugs, to comment that the attached patches have been deployed to production. This was work done in bug 1004617. However, there are several limitations:

1) We parse the bug number from the checkin comment, which historically can be either missing, or invalid
2) We have no guarantee that the landed patch is the same as the one attached to the bug
3) We have no easy way to match a discovered commit in the hg repo to a bug patch attachment
4 [review]) We do not have a "in production" flag for attachments
5) When we attach a patch, there is no meta data in bugzilla to define which repository the patch is against (as we have several under hg.mozilla.org/build)

An alternative workflow, that I would like to discuss in this bug, would look like this:

1) The RelEng author attaches a patch to a bug, and captures which repository this should be landed against in fields of the bug
2) The reviewer reviews, and if it is an r+, has the option to a) either directly land the patch *or* b) to hand it back to the author
2a) if landing, the repo would get updated, using the author's hg credentials (user settings) to generate correct hg headers, or if hg headers already exist (e.g. patch was created with hg export) would use those. Then there would be a possibility to call out to some callback triggers in releng systems, so that we could tie downstream workflow to this event
2b) if handing back to the author, it would disappear from the reviewers queue, and return to the author's queue, visibile from the "My Dashboard" page of the author. In his/her dashboard, he/she can see which bugs have been reviewed, and not yet landed. Directly from the dashboard, the author would be able to cancel the patch, or land it. The same callbacks described in 2a) would be called.

The motivation behind this idea is to:

a) allow a simpler workflow for the landing process of release engineering changes
b) to allow people to land other people's changes, if they r+ them, directly from bugzilla
c) to ensure that patches that are attached to bugs are the same ones that are committed in source control, and avoid "fuzzy matching" of patches "after the event"
d) to guarantee that commit comments contain correct bug numbers, when they are changes created directly from a bug
e) to improve the meta data related to patches in bugzilla, to track which repo they are patches for, which commits were actually landed, whether they are just checked in, or also in production
f) to simplify and improve auto deployment of release engineering changes, to have a full end-to-end integrated systems avoiding human errors

Comment 1

[Pete Moore [:pmoore][:pete]]

So - after more reading around, I've discovered all about the soon-to-come integration with Review Board (tracked under bug 515210) so I'm assuming this is all due to change - therefore it might make more sense to wait for 515210 to land, before thinking any further into this.

Thanks,
Pete