Add class to compute the code owner statuses for the files in a change
We need the code owner statuses for the files in a change for 2
purposes:
1. to implement a REST endpoint that returns them to the UI so that they
can be shown to the user
2. to check whether a change is submittable
In order for a change to be submittable every file, or rather touched
path, in a change needs to be approved by a code owner:
* New file:
requires approval on the new path
* Modified file:
requires approval on the path (old path == new path)
* Deleted file:
requires approval on the old path
* Renamed file:
requires approval on the old and new path (equivalent to delete old
path + add new path)
* Copied file:
requires approval on the new path (an approval on the old path is not
needed since the file at this path was not touched)
For every touched path the following code owner statuses are possible:
* INSUFFICIENT_REVIEWERS:
The path needs an owner approval, but none of its code owners is
currently a reviewer of the change.
* PENDING:
A code owner of this path has been added as reviewer, but no code
owner approval for this path has been given yet.
* APPROVED:
The path has been approved by a code owner or a code owners override
is present (code owner overrides will be implemented only later).
The new CodeOwnerApprovalCheck computes the code owner statuses for all
files/paths that were changed in the current revision of a change. For
this computation it iterates over the touched paths to look up the code
owners. The code owners are then matched against the reviewers/approvers
on the change.
Computing the code owner statuses for non-current revisions is not
supported since the semantics are unclear, e.g.:
* non-current revisions are never submittable, hence asking which code
owner approvals are still missing in order to make the revision
submittable makes no sense
* the code owner status PENDING doesn't make sense for an old
revision, from the perspective of the change owner this status looks
like the change is waiting for the code owner to approve, but since
voting on old revisions is not possible the code-owner is not able to
provide this approval
* the code owner statuses are computed from the approvals that were
given by code owners, the UI always shows the current approval even
when looking at an old revision, showing code owner statuses that
mismatch the shown approvals (because they are computed from approvals
that were present on an old revision) would only confuse users
In order for a path to be approved we require an explicit vote on the
required label. Later we will also consider an implicit approval from
the patch set uploader, if the patch set uploader is a code owner (but
this will only be implemented in a follow-up change, for now we have a
TODO for this in CodeOwnerApprovalCheck).
Signed-off-by: Edwin Kempin <ekempin@google.com>
Change-Id: I95ab49f4cd04633046c9072c4083b797ba6b59ee
10 files changed
