You want a GitHub Copilot agent to run automatically every time a pull request is opened against the main branch. The agent should analyze the diff and post a review comment. Which GitHub Actions workflow trigger and job configuration correctly invokes the agent in this CI context?
Select an answer to reveal the explanation.
Short Explanation and Infographic
Triggering an agent on pull request events is like setting up a doorbell — you want it to ring when someone arrives (PR opened/updated), not after they've already come inside (after merge). The pull_request trigger with types [opened, synchronize] fires exactly when the PR is created or updated with new commits, which is the right moment to analyze the diff and post a review. Running it post-merge (on push to main) defeats the purpose of a review entirely.
Full explanation below image
![A 2048x1536 landscape infographic titled 'Invoking a Copilot Agent in CI — Pull Request Workflow'. Top shows a timeline: Developer Opens PR → Workflow Trigger Fires (pullrequest: opened/synchronize) → GitHub Actions Job Starts → Agent Step Runs → Agent Analyzes Diff → Posts Review Comment on PR. Center shows the YAML snippet: 'on: pullrequest: types: [opened, synchronize]' and a job step calling the agent action with inputs: pr-number and diff-url. Bottom left shows what NOT to use: schedule (clock icon, red X), push to main (merge icon, red X). Bottom right: green checkmark on the pullrequest trigger. GitHub green and navy color scheme, workflow diagram style.](/media/github/gh-600/GH-600-e2-q016-infographic.webp)
Full Explanation
GitHub Actions workflows are event-driven. Selecting the correct trigger is the first step; then the job must properly invoke the agent with the right context.
Option A is incorrect. A scheduled trigger polling every 15 minutes introduces latency, wastes compute on runs with no new PRs, and is complex to implement correctly (needing to fetch and iterate open PRs). It is not a real-time response to PR creation and is not the right pattern for CI review automation.
Option B is correct. The pull_request event with types: [opened, synchronize] fires immediately when a PR is opened (opened) or when new commits are pushed to the PR branch (synchronize). This covers both the initial PR and subsequent updates. In the workflow job, the agent step receives the PR context (number, head SHA, diff URL, etc.) via GitHub context variables (${{ github.event.pull_request.number }}, etc.) and uses these to fetch the diff and post review comments via the GitHub API. The agent action may use GITHUB_TOKEN with write permissions on pull-requests to post comments.
Option C is incorrect. repository_dispatch requires an external HTTP POST to trigger it. While valid for some automation scenarios, it requires the PR author to manually fire the event — which breaks the automatic CI review use case and creates friction. This trigger is designed for external system integration, not automatic PR review.
Option D is incorrect. A push to main event fires after the PR is merged. A code review agent running at this point cannot inform the merge decision. The review would be retroactive and the comment would appear on a merged PR branch, which is not the intended workflow.
Key pattern: on: pull_request for real-time PR review automation; pass PR context via GitHub Actions context expressions to the agent step.