commit 898287b67b68e402822ed8b7668df0671dede149
author Edwin Kempin <ekempin@google.com> Fri Mar 22 14:10:37 2019 +0100
committer Edwin Kempin <ekempin@google.com> Thu Apr 04 11:02:21 2019 +0200
tree 5be727dd6e064fa3f026f3449225fb5f6c88c364
parent 070ee9b094d9d401302fe4a1b6156eedd56f10d0

Change List Pending Checks REST endpoint to accept a query as input

At the moment the List Pending Checks REST endpoint supports 2 URL
parameters:

1. checker: checker UUID (requried)
2. state: check state (optional, can be specified multiple times)

Later we would need another URL parameter for the checker scheme.

In the future the List Pending Checks REST endpoint should be
implemented on top of a new check index. This means the List Pending
Checks REST endpoint will execute a query on the check index.

Keeping this in mind we want to make the List Pending Checks REST
endpoint already now consistent with other Query REST endpoints (e.g.
QueryAccounts, QueryChanges) so that we don't break callers when we
migrate this REST endpoint on top of a check index.

All existing query REST endpoints take a query string as input (via a
'query' URL parameter). To be consistent the List Pending REST endpoint
should also expect a query string as input.

The current URL parameters are transitioned to operators in the input
query. This means instead of

  GET /plugins/checks~checks.pending/?checker=<checker-uuid>&state=<state>

one would now call

  GET /plugins/checks~checks.pending/?query=checker:<checker-uuid>+state:<state>

With this syntax we allow users to make full use of the flexibility that
an index provides, once we have a check index.

While there is no check index yet there are some limitations for the
query:
1. exactly 1 checker predicate must be used
2. the checker predicate must either be the root predicate
   (query = "checker:<checker-uuid>") or the root predicate must be an
   'and' predicate that has a checker predicate as immediate child
   (query = "checker:<checker-uuid> AND ...")

These limitations will be removed when we implement a check index.

For now we implement the List Pending Checks REST endpoint like this:
1. implement a CheckQueryBuilder which supports a 'checker' and a
   'state' operator, use the CheckQueryBuilder to parse the query
2. validate the query against the limitations mentioned above (expect
   exactly 1 checker predicate at root or as immediate child of an 'and'
   predicate at root)
3. add 'AND state:NOT_STARTED' if no state predicate was used
4. get the checker UUID from the 1 checker predicate in the query and
   load the checker config
5. use the query of the checker to query for matching changes via the
   change index
6. For each change:
   a. load the check for the checker
   b. create a backfilled check if no such check exists (the checker's
      query matched the change hence it is relevant and backfilling
      should be done)
   c. check if the input query matches the check (by converting the
      predicate to Matchable and invoking the match(Check) method)
   d. create PendingChecksInfo if the check was matched

The extension API and the tests have been adapted to the new REST API.

The behavior of the List Pending REST endpoint is unchanges, except for
listing pending checks of a non-existing checker. We now return an empty
list in this case (the non-existing checker doesn't match any check),
before we failed with a UnprocessableEntityException ("checker
<checker-uuid> not found"). The new behavior is better since it doesn't
allow callers to probe whether a checker exists.

Change-Id: Ide4cb6507571f9159f39ca1dc0f505944f48b5e4
Signed-off-by: Edwin Kempin <ekempin@google.com>