Publish pr-check Results

Post the pr-check Results Summary as a comment on an existing GitHub PR, ending the comment with a hidden marker. The webhook parses that marker and applies the pr-check commit status to the tested SHA and the pr-check - <state> label to the PR — this skill never writes the status or label itself, so it works the same whether or not the user has write access on the target repository.

Newly created PRs do not need this skill: the pr skill writes the same Results Summary and marker into the PR description at creation, and the webhook reads it from there. Reach for this skill only to record a later run — for example after pushing more commits and rerunning pr-check on an open PR — where the description no longer reflects the current head.

Input

Pull Request

${ARGUMENTS} carries a PR URL of the form https://github.com/<target-org>/<repository>/pull/<number>, where <repository> is liferay-portal or liferay-portal-ee. The webhook applies the status and label to a pull request in either. When missing or malformed, abort and ask the user for the URL.

Results Summary

Use the Results Summary block emitted by the pr-check run in the current session — the overall state line, the tested SHA, the table of validations, and every note appended below it. Any row can carry a note, a PASS included, so carry them all verbatim. When no Results Summary is available (pr-check has not run this session), abort and ask the user to run pr-check first; this skill records a run, it does not perform one.

The tested SHA must be the current head of the pull request:

gh pr view \
	--jq .headRefOid \
	--json headRefOid \
	"<pr-url>"

A session can hold runs of several branches, so use the Results Summary whose tested SHA is that head. When none matches, abort without posting and name the head SHA and every tested SHA. Posting a run of any other commit would record its status on a commit that the pull request does not show.

Expected Output

Posted Comment

Post a fresh comment on each run rather than editing a prior one, so the PR keeps a chronological record. The comment body is the Results Summary verbatim, a blank line, then the marker — an HTML comment, invisible in rendered Markdown, whose payload is a JSON object of the form <!-- pr-check {"result": "<state>", "sha": "<tested-SHA>"} -->, where <state> is success when the overall state is PASS and failure when it is FAIL, so a run carrying NO COVERAGE or NOT VERIFIED rows records success, and <tested-SHA> is the full 40-character SHA from the Results Summary:

**pr-check: PASS** — tested on `<tested-SHA>`

| Validation | Result |
| --- | --- |
| Source Format | PASS |
| Full Portal Build | PASS |
| Java Unit Tests | PASS |

<!-- pr-check {"result": "success", "sha": "<tested-SHA>"} -->

When build/test-plan/result.json exists and its head is the tested SHA, add a Test plan: <count> run, <passed> passed. line between the Results Summary block and the marker. Leave it out otherwise. Put a blank line before and after it. <count> is the number of entries in tests. <passed> is the number of those entries whose result is passed.

Post the body with --body-file, or with --body from a quoted-heredoc variable; either keeps the marker's literal ! off the command line, where it could otherwise trigger history expansion and corrupt the marker. Use mktemp for the file so it stays out of the working tree, and remove it afterward.

comment_file=$(mktemp)

gh pr comment \
	--body-file "${comment_file}" \
	"<pr-url>"

rm "${comment_file}"

When the comment fails to post, surface the error — without it the webhook has nothing to parse, so the status and label will not appear.

Summary

Report back to the user with:

• The comment URL and the tested SHA the marker records.
• That the pr-check commit status and pr-check - <state> label are applied by the webhook once it processes the comment, and so may lag the comment by a moment.