Merge changes Ie0e40ee9,Ifcc30aaa into stable-3.6

* changes:
  Document ChecksApi.updateResult()
  Document `check-result-expanded` plugin endpoint

3 files changed, 45 insertions, 4 deletions

diff --git a/Documentation/pg-plugin-checks-api.txt b/Documentation/pg-plugin-checks-api.txt
index 8786cc4e25..ebfb8624d9 100644
--- a/Documentation/pg-plugin-checks-api.txt
+++ b/Documentation/pg-plugin-checks-api.txt
@@ -42,3 +42,23 @@ Here are some examples of open source plugins that make use of the Checks API:
 `checksApi.announceUpdate()`
 
 Tells Gerrit to call `provider.fetch()`.
+
+[[updateResult]]
+== updateResult
+`checksApi.updateResult(run: CheckRun, result: CheckResult)`
+
+Updates an individual result. This can be used for lazy laoding detailled
+information. For example, if you are using the
+link:pg-plugin-endpoints.html#_check_result_expanded[`check-result-expanded`
+endpoint], then you can load more result details when the user expands a result
+row.
+
+The parameter `run` is only used to *find* the correct run for updating the
+result. It will only be used for comparing `change`, `patchset`, `attempt` and
+`checkName`. Its properties other than `results` will not be updated.
+
+For us being able to identify the result that you want to update you have to
+set the `externalId` property. An undefined `externalId` will result in an
+error.
+
+An example usage can be found in link:https://chromium.googlesource.com/infra/gerrit-plugins/buildbucket/+/main/web/checks-result.ts[Chromium Buildbucket Plugin].
diff --git a/Documentation/pg-plugin-endpoints.txt b/Documentation/pg-plugin-endpoints.txt
index f2a72f1d4d..2227e79471 100644
--- a/Documentation/pg-plugin-endpoints.txt
+++ b/Documentation/pg-plugin-endpoints.txt
@@ -86,6 +86,25 @@ link:rest-api-changes.html#revision-info[RevisionInfo]
 labels with scores applied to the change, map of the label names to
 link:rest-api-changes.html#label-info[LabelInfo] entries
 
+=== check-result-expanded
+The `check-result-expanded` extension point is attached to a result
+of the link:pg-plugin-checks-api.html[ChecksAPI] when it is expanded. This can
+be used to attach a Web Component displaying results instead of the
+`CheckResult.message` field which is limited to raw unformatted text.
+
+In addition to default parameters, the following are available:
+
+* `result`
++
+The `CheckResult` object for the currently expanded result row.
+
+* `run`
++
+Same as `result`. The `CheckRun` object is not passed to the endpoint.
+
+The end point contains the `<gr-formatted-text>` element holding the
+`CheckResult.message` (if any was set).
+
 === robot-comment-controls
 The `robot-comment-controls` extension point is located inside each comment
 rendered on the diff page, and is only visible when the comment is a robot
@@ -237,4 +256,4 @@ In addition to default parameters, the following are available:
 
 * `accountId`
 +
-the Id of the account that the status icon should correspond to.
\ No newline at end of file
+the Id of the account that the status icon should correspond to.
diff --git a/polygerrit-ui/app/api/checks.ts b/polygerrit-ui/app/api/checks.ts
index aa0b05d9f9..3d2b1bd865 100644
--- a/polygerrit-ui/app/api/checks.ts
+++ b/polygerrit-ui/app/api/checks.ts
@@ -387,9 +387,11 @@ export declare interface CheckResult {
    * responsible for not killing the browser. :-)
    *
    * For now this is just a plain unformatted string. The only formatting
-   * applied is the one that Gerrit also applies to human comments. TBD: Both
-   * human comments and check result messages should get richer formatting
-   * options.
+   * applied is the one that Gerrit also applies to human comments.
+   *
+   * To provide richer formatting to the check result messages you should use
+   * the `check-result-expanded` plugin endpoint to attach a Web Component.
+   * See `Documentation/pg-plugin-endpoints.txt`.
    */
   message?: string;