feat(action): add optional pr_number input and workflow_run fallback - #1156
Open
ylcn91 wants to merge 2 commits into
Open
feat(action): add optional pr_number input and workflow_run fallback#1156ylcn91 wants to merge 2 commits into
ylcn91 wants to merge 2 commits into
Conversation
|
|
Contributor
|
🔍 OpenCodeReview found 1 issue(s) in this PR.
|
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
The pull request number was read from the event payload in two places: the fetch step's `github.event.pull_request.number || github.event.issue.number`, and `context.issue.number` in the range and posting steps. Neither resolves on `workflow_run`, whose payload names the pull request only under `workflow_run.pull_requests[0]`. The review therefore ran to completion and the posting step then requested /repos/OWNER/REPO/issues//comments, got a 404, and the findings were lost. "Resolve PR refs" now resolves the number once — the new optional `pr_number` input, then the event payload, then `workflow_run.pull_requests[0].number` — publishes it as $PR_NUMBER, and fails there when nothing resolves or the value is not a PR number, before OCR is installed or any LLM quota is spent. The head fetch, the checkpoint resolver and the posting step all read that one value; runPostReviewComments takes it as an option and still falls back to context.issue.number when a caller omits it. Behavior is unchanged for pull_request, pull_request_target and issue_comment: an unset input falls through to the existing resolution. Closes alibaba#1150
The review guidelines rule out loose equality, so spell out the null and undefined checks that `!= null` covered.
ylcn91
force-pushed
the
feat/action-pr-number-input
branch
from
September 7, 2026 06:25
efa02a1 to
b30dd5c
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
On
workflow_runthe action found no pull request number. The fetch step readgithub.event.pull_request.number || github.event.issue.numberand the range and posting steps readcontext.issue.number; none of them resolve for that event, whose payload names the pull request only underworkflow_run.pull_requests[0]. The review ran to completion, the posting step requested/repos/OWNER/REPO/issues//comments, got a 404, and the findings were lost.A new "Resolve PR refs" step resolves the number once, in this order: the new optional
pr_numberinput, then the event payload, thenworkflow_run.pull_requests[0].number. It publishes the value as$PR_NUMBERand fails right there, before OCR is installed or any LLM quota is spent, when nothing resolves or the value is not a PR number. The head fetch, the checkpoint resolver and the posting step all read that one value;runPostReviewCommentstakes it as an option and still falls back tocontext.issue.numberwhen a caller omits it.pull_request,pull_request_targetandissue_commentbehave as before: an unset input falls through to the existing resolution.Type of Change
How Has This Been Tested?
make testpasses locallyManual testing (describe below)
npm run test:github-actions: new action-contract cases cover the resolution order, theworkflow_runfallback, the early failure on a missing or non-numeric value, and theprNumberoption ofrunPostReviewCommentstogether with its existingcontext.issue.numberfallback.make teston this branch (Go packages plus the node script tests).Only
action.yml, the scripts underscripts/github-actions/andexamples/github_actions/README.mdchange; there is no Go change.Checklist
go fmt,go vet)Related Issues
Closes #1150