I see, I set it up to check that the CL wasn't marked CQ-1 or Verified-1. I'll add a check to make sure that the CQ+1 tag was actually removed by chromeos-bot.

Note that when the bot removes CQ+1, it does so by forging identity (because it has to act under the identity of the original +1er in order to remove their vote). So #2 may or may not be easy to accomplish.


Regarding original post, yes, this is a new bot we are rolling out. For a number of reasons, developers should not be modifying their change while it is in the CQ, the CQ +1 button should be considered a "I want this to be submitted" vote. This new bot is just one more reason. If #2 turns out to be difficult to implement, I don't think that should block us from rolling out this otherwise highly useful bot. Therefore, reducing to P2.

> the CQ +1 button should be considered a "I want this to be submitted" vote

Sure, but there may always be reasons why you'd want to change your opinion later on. People may forget things or make mistakes. The only alternative is to submit a revert right afterwards which is way more hassle for everyone, so I think it's important to preserve the existing ways to stop a CL at the last minute (both by owner removing Commit-Ready+1 and by someone else setting Code-Review-2).

Setting CR-2 or V-1 are suitable ways to change your mind later on, and the exonerator bot will not touch those bits.

Re: #3 

It is possible to tell from the API response that the identity is forged: each message has an "author" and "real_author" field. We can check for whether the most recent CQ+1 bit removal has msg['real_author']['email'] = 'chromeos-commit-bot@..."

While Aviv's point stands that setting CQ-1 or V-1 would work, I think this is a reasonable request - I'd like the bot to have as few landmines as possible.

Oops, I forgot to mention that CR-(1|2) also works

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/infra/cl_exonerator/+/d028360ec476357b7c584a5ee7874663342fb061

commit d028360ec476357b7c584a5ee7874663342fb061
Author: Paul Hobbs <phobbs@google.com>
Date: Fri Dec 01 03:53:56 2017

Make _ShouldBeMarkedReady more robust.

Added check for _CQApprovalWasRemovedByBot.

TEST=Added unit test cases for human and bot CQ+1 removal.
BUG= chromium:789222 

Change-Id: I90995c94f0f3db48f84728f21314e011407f6368

[modify] https://crrev.com/d028360ec476357b7c584a5ee7874663342fb061/Pipfile.lock
[add] https://crrev.com/d028360ec476357b7c584a5ee7874663342fb061/exonerator/test_cases/ready_for_exoneration_710511.json
[add] https://crrev.com/d028360ec476357b7c584a5ee7874663342fb061/exonerator/test_cases/CQ_bit_removed_by_bot_710511.json
[modify] https://crrev.com/d028360ec476357b7c584a5ee7874663342fb061/.gitignore
[add] https://crrev.com/d028360ec476357b7c584a5ee7874663342fb061/exonerator/gerrit_test.py
[add] https://crrev.com/d028360ec476357b7c584a5ee7874663342fb061/exonerator/test_cases/CQ_bit_removed_by_human_676269.json
[modify] https://crrev.com/d028360ec476357b7c584a5ee7874663342fb061/Pipfile
[modify] https://crrev.com/d028360ec476357b7c584a5ee7874663342fb061/exonerator/gerrit.py

Looks like this still happens? odd, because I added a unit test for the CQ-bit-removed-by-human case...

 Issue 794672  has been merged into this issue.