Recipe roller should deal better with reverts |
|||||
Issue descriptionThe roller doesn't respect reverts well. Example: https://chromereviews.googleplex.com/506247013 and https://chromereviews.googleplex.com/503367013 Would this be completely solved by pawel's proposed change? Is there anything else we need to do to make sure reverts are handled correctly?
,
Sep 15 2016
,
Sep 15 2016
Stephen, in case of above CLs, what'd be the better way we seek? If it's producing one trivial roll containing both the breaking CL and its revert, then yes, what I suggested in https://groups.google.com/a/chromium.org/d/msg/infra-dev/71dXu2JnJxo/zjS_lnlyBQAJ would have that effect - unless the first nontrivial roll gets LGTM-ed and lands before the revert.
,
Sep 15 2016
Ok, that makes sense. Actually, I thought of another situation we should deal with well. Currently, if a CL rolls downstream, and breaks the downstream code, and is reverted, the roller will just try to land that CL again. The roller will not obey the revert which was issued downstream. The worst case would be that a trivial roll causes this issue, which needs to get reverted. The roller would keep trying to re-land this CL, which would be pretty annoying. I chatted with dnj@, and we would suggest that we should also disable the autoroller in the repo which had the outage (with some sort of recipes.cfg flag). Maybe that's enough, but we should document that somewhere.
,
May 15 2017
This particular bug is fixed, but the theme is still there. deduping into 718420 which is the modern version of this bug. |
|||||
►
Sign in to add a comment |
|||||
Comment 1 by martiniss@chromium.org
, Sep 14 2016Components: Infra>Platform>Recipes
Labels: -OS-Linux -Pri-3 Pri-2
Status: Available (was: Unconfirmed)