Skip to content

Support ready_for_review for pull_request_target triggers #41161

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
pelikhan merged 2 commits into from
Jun 24, 2026
Merged

Support ready_for_review for pull_request_target triggers #41161

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
e33efaf
Initial plan
Copilot Jun 24, 2026
959c640
Implement trigger schema fix
Copilot Jun 24, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
13 changes: 13 additions & 0 deletions pkg/parser/schema_location_test.go
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -166,6 +166,19 @@ func TestValidateMainWorkflowFrontmatterWithSchemaAndLocation(t *testing.T) {
filePath: "/test/workflow.md",
wantErr: false,
},
{
name: "valid pull_request_target ready_for_review trigger",
frontmatter: map[string]any{
"on": map[string]any{
"pull_request_target": map[string]any{
"types": []any{"ready_for_review"},

@github-actions github-actions Bot Jun 24, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[/tdd] The new test verifies ready_for_review in isolation, but the PR description highlights the motivating real-world pattern as types: [opened, ready_for_review]. A combination test would better capture that scenario and guard against any future combinatorial validation bugs.

💡 Suggested additional test case 
{
    name: "valid pull_request_target combined types trigger",
    frontmatter: map[string]any{
        "on": map[string]any{
            "pull_request_target": map[string]any{
                "types": []any{"opened", "ready_for_review"},
            },
        },
        "engine": "claude",
    },
    filePath: "/test/workflow.md",
    wantErr:  false,
},

This mirrors the example in the PR description and ensures the enum validation works correctly when multiple types are combined.

},
},
"engine": "claude",
},
filePath: "/test/workflow.md",
wantErr: false,
},
{
name: "invalid workflow frontmatter with location",
frontmatter: map[string]any{
Expand Down
1 change: 1 addition & 0 deletions pkg/parser/schemas/main_workflow_schema.json
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -1410,6 +1410,7 @@
"reopened",
"synchronize",
"converted_to_draft",
"ready_for_review",

@github-actions github-actions Bot Jun 24, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[/grill-with-docs] pull_request_target.types now has both converted_to_draft and ready_for_review, but the description field (line 1399) still reads "List of pull request target event types to trigger on" — missing the helpful note that pull_request.types carries about these being logically opposite state transitions.

💡 Suggested description update

At line 1399, change:

"description": "List of pull request target event types to trigger on"

to mirror pull_request.types:

"description": "Pull request target event types to trigger on. Note: converted_to_draft and ready_for_review represent state transitions rather than states. While technically valid to listen for both, consider if you need to handle both transitions or just one."

And add the $comment:

"$comment": "converted_to_draft and ready_for_review are logically opposite state transitions. Using both may indicate unclear intent."

This keeps both event definitions consistent and surfaces the guidance to tooling that renders schema descriptions.

@github-actions github-actions Bot Jun 24, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Incomplete parity fix: milestoned and demilestoned are still absent from the pull_request_target.types enum even though this PR's premise is that the two events share the same activity types.

💡 Details

The pull_request enum includes both milestoned and demilestoned, but neither was added to pull_request_target. According to the GitHub Actions docs, pull_request_target supports the same set of activity types as pull_request.

Users who write:

on:
  pull_request_target:
    types: [milestoned]

will still get a schema validation error after this PR merges.

Add "milestoned" and "demilestoned" to the pull_request_target.types enum (alongside the existing entries) to complete the parity fix. A corresponding test case would also pin the behaviour.

"locked",
"unlocked",
"enqueued",
Expand Down
Loading