Re: minutes of ESC call ...

On Sun, Jul 3, 2016 at 3:59 PM, David Ostrovsky <d.ostrovsky@gmx.de> wrote:
> 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.

No, although using 3 different back-end is indeed a confused design.
and yes H2 is off-limit.. but NoteDB hopefully will not be hidden
behind a wall of java crap, so presumably there will be way to access
the content efficiently.


> 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.

Because stream does not contain the necessary information to get the data...
when I get a stream message about an approval +2 I do not know if that
change was +1 verified by gerrit

> 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?

I do not want to but I may have to.
for instance how exactly do you handle duplicate account using 'gerrit
front end' ?

> 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@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

select change_id || ',' || patch_set_id from patch_set_approvals where
change_id in (select c.change_id from changes c, patch_sets p,
patch_set_approvals a where status = 'n' and c.change_id = p.change_id
and c.change_id = a.change_id and p.patch_set_id =
c.current_patch_set_id and a.patch_set_id = c.current_patch_set_id and
p.uploader_account_id = a.account_id and a.category_id = 'Code-Review'
and a.value = 2) and category_id = 'Verified' and value = 1 and
account_id = 1000855

 time ./auto_merge_candidate
26347,1

real    0m0.430s
user    0m0.044s
sys    0m0.056s

how do you suggest to write that in 'GQL' query ? (note: teh querry
above is missing a filter on the 'master' branch but that is trivial
to add )

> 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.

yeah except you need to find a way to analyze the result of this not
not try over and over again to submit the same patch that won't go for
some reason (merge conflict for instance). and yeah I have that
problem too.. that is the thing with production-grade automation... it
is not about the easy 95% bits.. it is about the killer corner-case...

Norbert