commit bfa633ffec0be8997ba978551b97846c71ea4be8
author Edwin Kempin <ekempin@google.com> Mon May 17 14:16:17 2021 +0000
committer Edwin Kempin <ekempin@google.com> Mon May 31 11:30:54 2021 +0200
tree c24b5f9943612f5063c07e27f046950733a2a8ed
parent aece6768ca5dde67cf6df2afd9593f85ac4ceb73

PathCodeOwnerStatus: Include a reason explaining the status

The functionality of the code-owners plugin has grown over time and
there are more and more possibilities how files can get code owner
approved (e.g. explicit approval by regular/default/fallback/global code
owner, implicit approval by regular/default/fallback/global code owner,
override, exempted user, exempted pure revert).

At the moment the UI is only showing the code owner status for files,
but doesn't tell the user the reason for the state. Since there a many
different reasons for the same state, users have a hard time
understanding the state. To address this we want to show the user a
reason for the state that explains why it was set.

As a first step towards this PathCodeOwnerStatus can now contain a list
of reasons explaining the state. The reasons are populated by
CodeOwnerApprovalCheck when the status is set to APPROVED or PENDING
(for INSUFFICIENT_REVIEWERS no reason is set as this state is
self-explaining and the reason would be always the same).

PathCodeOwnerStatus accepts a list of reasons, but for now we are at
most setting a single reason. It's a list so that we can easily expand
this in the future if necessary. Having it as a list already now will be
important for the REST API where we cannot make incompatible changes
like switching from a single reason to a list of reasons.

Reasons are messages that can be shown to the user. These messages can
reference accounts via the same placeholders that are also used in
change messages. The frontend needs to replace the placeholders before
showing the reason messages to the user. The usage of placeholders,
instead of hard-coding the user names, allows the frontend to use
dedicated controls for showing the account information (e.g. show the
user name, but make additional account information available via a
hovercard).

The following next steps will be implemented in follow-up changes:
1. Return the reasons to the caller (extend the JSON entities to include
   the reasons and the account infos).
2. Extend the frontend to show the reasons to the user.

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