minutes of ESC call ...

[David Ostrovsky]

On Thu Jun 30 15:46:27 UTC 2016 Michael Meeks wrote:

[...]
>* Pending Action Items:
[...]
>    + investigate a cron job that queries & auto-merges (Norbert)
>         + if +2 by author and +1 by jenkins -> auto-push (on-going)
>            + SQL query done.. but yield interesting result...
>                  https://gerrit.libreoffice.org/#/c/26347/  which 1/
is marked
>                  'not mergeable' but I can't yet detect that
>              and really should not be merged anyway.. based on
comments.
>                  + Not found a way to detect this yet.

I think you are confused.

I do not have a better explanation how you came to the idea to mess
around with backend details of the persistent layer for change meta
data in Gerrit Code Review. As you have noticed, not everything is
stored in the database, e.g. mergeability bit is stored in the
persistent (H2-based) cache. But it's even worth: as you may know, the
database layer for change meta data is already migrated to the GIT
storage (NoteDb) on Gerrit master, so everything that seems to work
today per SQL query would stop to work tomorrow, after upgrade.

In the end you probably don't use emacs, to access content.xml from ODT
file, if you want to read it, don't you? You would rather use a
frontend application (writer?) to do the job.

What you want to use instead here is the Gerrit frontend: Query
Language that is mapped to the right backend pieces and would adjust
the predicates once the data they are accessing is moved from the
database to persistent caches or GIT storage so the API is remaining
stable for the user (frontend is backend implementation agnostic,
obviously).

So the GQL query you are looking for, that is executed through SSH
query command, is:

$ ssh logerrit gerrit query "'project:core is:open is:mergeable
label:Code-Review+2 label:Verified+1,ci at libreoffice.org NOT label:Code
-Review-2 NOT label:Verified-1'"

The result of it right now on gerrit.libreoffice.org are these two
changes: 26566, 26308.

You could use query --format json option and parse it with a couple of
lines of python script, or alternatively you could add --current-patch
-set option and grep for the "  revision:" line:

$ ssh logerrit gerrit query --current-patch-set "'project:core ...'" | 
grep "  revision:" | awk '{print $2}'
50d05404589960804ebaba6d1ffa5afeddd1df6d
d145feafa6c8c94b3848ecbbd624d2ceb1904b2f

This would dump the commit ids to supply to the gerrit review command.
Iterating over the result above and calling (untested):

$ ssh logerrit gerrit review --submit <commit>

with a user that has required ACL, should do the job.