In deps_updater.py: After updating, set commit and close on CQ failure.

In deps_updater.py: After updating, set commit and close on CQ failure.

Currently, w3c-test-autoroller:
 1. Uploads a CL.
 2. Triggers try jobs on Blink try bots.
 3. Waits for try job results (which are failing).
 4. Modifies TestExpectations and commits.
 5. Uploads another patch.
 6. Calls `git cl land -f --auth-refresh-token-json ...`.

I think that when landing CLs, w3c-test-autoroller commits
should go through the CQ, and if the CQ fails even after
updating TestExpectations etc., then the CL should be closed.

BUG=629275
Committed: https://crrev.com/c6c68eeb5dd4ccf9fa0e7bf97c5999d31d4fd9cc
Cr-Commit-Position: refs/heads/master@{#412589}

[qyearsley, 2016-08-15 22:49:45]

qyearsley@chromium.org changed reviewers:
+ dpranke@chromium.org, jsbell@chromium.org

[qyearsley, 2016-08-15 22:49:46]

Currently, w3c-test-autoroller:
 1. Uploads a CL.
 2. Triggers try jobs on Blink try bots.
 3. Waits for try job results (which are failing).
 4. Modifies TestExpectations and commits.
 5. Uploads another patch.
 6. Calls `git cl land -f --auth-refresh-token-json ...`.

I think that when landing CLs, w3c-test-autoroller commits should go through the
CQ, and if the CQ fails even after updating TestExpectations etc., then the CL
should be closed.

Additionally and separately, recent attempts by this bot are failing (example
log
https://luci-logdog.appspot.com/v/?s=chromium%2Fbb%2Fchromium.infra.cron%2Fw3...)
-- I think that this is because Gerrit has just been set as the default code
review tool for git cl upload in the infra repo, and we now need to explicitly
specify Rietveld.

[qyearsley, 2016-08-15 23:33:36]

Description was changed from

==========
In deps_updater.py: After updating, set commit and close on CQ failure.

BUG=629275
==========

to

==========
In deps_updater.py: After updating, set commit and close on CQ failure.

Currently, w3c-test-autoroller:
 1. Uploads a CL.
 2. Triggers try jobs on Blink try bots.
 3. Waits for try job results (which are failing).
 4. Modifies TestExpectations and commits.
 5. Uploads another patch.
 6. Calls `git cl land -f --auth-refresh-token-json ...`.

I think that when landing CLs, w3c-test-autoroller commits
should go through the CQ, and if the CQ fails even after
updating TestExpectations etc., then the CL should be closed.

BUG=629275
==========

[qyearsley, 2016-08-15 23:33:41]

The CQ bit was checked by qyearsley@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-08-15 23:33:52]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[Dirk Pranke, 2016-08-15 23:42:52]

Do we have a mechanism for detecting that the commits are failing? What's to
keep us from auto-closing the CLs and not realizing that nothing is landing (and
then generating a bunch of load trying to re-land rolls that will never land)?

[commit-bot: I haz the power, 2016-08-16 00:55:44]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-08-16 00:55:45]

Dry run: This issue passed the CQ dry run.

[qyearsley, 2016-08-16 22:35:59]

On 2016/08/15 at 23:42:52, dpranke wrote:
> Do we have a mechanism for detecting that the commits are failing? What's to
keep us from auto-closing the CLs and not realizing that nothing is landing (and
then generating a bunch of load trying to re-land rolls that will never land)?

What I was expecting is that builds should always be green when the bot is
either doing nothing or successfully committing; and builds should be red when
there are changes but it fails to commit. (If the build is green when it fails
to commit, this is a bug that I should fix.) I was expecting that at first I'd
be responsible for checking whether the builds are green or red; then, perhaps
if this is what's done for other similar bots on chromium.infra.cron, it could
be watched by a sheriff/trooper rotation.

Does that seem right?

https://codereview.chromium.org/2248913003/diff/20001/third_party/WebKit/Tool...
File third_party/WebKit/Tools/Scripts/webkitpy/w3c/deps_updater.py (right):

https://codereview.chromium.org/2248913003/diff/20001/third_party/WebKit/Tool...
third_party/WebKit/Tools/Scripts/webkitpy/w3c/deps_updater.py:90: return 1
Note, this CL should make it so that after trying to commit, the script then
waits for all of the try jobs (in the CQ) to finish; if there are any failing
try jobs, then the main method should return 1 after closing the CL.

So, if there are any failing CQ try jobs then the overall script should have a
non-zero exit code, and I'm assuming that this should turn the step and the
build red.

I haven't tried this out yet though.

[Dirk Pranke, 2016-08-17 01:47:20]

On 2016/08/16 22:35:59, qyearsley wrote:
> On 2016/08/15 at 23:42:52, dpranke wrote:
> > Do we have a mechanism for detecting that the commits are failing? What's to
> keep us from auto-closing the CLs and not realizing that nothing is landing
(and
> then generating a bunch of load trying to re-land rolls that will never land)?
> 
> What I was expecting is that builds should always be green when the bot is
> either doing nothing or successfully committing; and builds should be red when
> there are changes but it fails to commit. (If the build is green when it fails
> to commit, this is a bug that I should fix.) I was expecting that at first I'd
> be responsible for checking whether the builds are green or red; then, perhaps
> if this is what's done for other similar bots on chromium.infra.cron, it could
> be watched by a sheriff/trooper rotation.
> 
> Does that seem right?

That seems okay as a first attempt.

[Dirk Pranke, 2016-08-17 01:47:26]

lgtm

[qyearsley, 2016-08-17 17:03:26]

The CQ bit was checked by qyearsley@chromium.org

[qyearsley, 2016-08-17 17:03:27]

The patchset sent to the CQ was uploaded after l-g-t-m from dpranke@chromium.org
Link to the patchset: https://codereview.chromium.org/2248913003/#ps40001
(title: "Rebased")

[commit-bot: I haz the power, 2016-08-17 17:04:01]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-08-17 18:18:23]

Committed patchset #3 (id:40001)

[commit-bot: I haz the power, 2016-08-17 18:26:43]

Description was changed from

==========
In deps_updater.py: After updating, set commit and close on CQ failure.

Currently, w3c-test-autoroller:
 1. Uploads a CL.
 2. Triggers try jobs on Blink try bots.
 3. Waits for try job results (which are failing).
 4. Modifies TestExpectations and commits.
 5. Uploads another patch.
 6. Calls `git cl land -f --auth-refresh-token-json ...`.

I think that when landing CLs, w3c-test-autoroller commits
should go through the CQ, and if the CQ fails even after
updating TestExpectations etc., then the CL should be closed.

BUG=629275
==========

to

==========
In deps_updater.py: After updating, set commit and close on CQ failure.

Currently, w3c-test-autoroller:
 1. Uploads a CL.
 2. Triggers try jobs on Blink try bots.
 3. Waits for try job results (which are failing).
 4. Modifies TestExpectations and commits.
 5. Uploads another patch.
 6. Calls `git cl land -f --auth-refresh-token-json ...`.

I think that when landing CLs, w3c-test-autoroller commits
should go through the CQ, and if the CQ fails even after
updating TestExpectations etc., then the CL should be closed.

BUG=629275

Committed: https://crrev.com/c6c68eeb5dd4ccf9fa0e7bf97c5999d31d4fd9cc
Cr-Commit-Position: refs/heads/master@{#412589}
==========

[commit-bot: I haz the power, 2016-08-17 18:26:44]

Patchset 3 (id:??) landed as
https://crrev.com/c6c68eeb5dd4ccf9fa0e7bf97c5999d31d4fd9cc
Cr-Commit-Position: refs/heads/master@{#412589}