Fork pull requests

PRs from forks are the tricky case for any commenting Action, because GitHub gives them a read-only token and withholds secrets. eval-action is built to degrade safely here.

What happens on a fork PR

• The evals run and the diff is computed — the check still reports pass/fail.
• The sticky comment step hits a 401/403 on the read-only token, so it is skipped with a notice rather than failing the Action.
• fail-on-regression still works: the gate is the check’s exit code, not the comment — so a regression still turns the check red.
• The action outputs (has-regression, regressions, summary) are still set.

In short: on a fork PR you lose the comment, but you keep the gate.

Why no pull_request_target

It would be tempting to use pull_request_target to get a write token (and a comment) on fork PRs. eval-action deliberately does not — that trigger runs in the context of the base repo with access to secrets while checking out untrusted PR code, a well-known privilege-escalation footgun. Keep your workflow on pull_request:

on:
  pull_request:        # NOT pull_request_target
    branches: [main]

Forks don't get your secrets

On a pull_request from a fork, repository secrets are not available — so a real-provider run (use-mock: 'false') won’t have a key on fork PRs. The mock default is the fork-safe choice; reserve real-provider runs for same-repo (branch) PRs, or run them in a separate, manually-approved workflow.

Seeing the diff without a comment

When the comment is skipped, the diff still lives in the job logs and the run summary, and the summary output is available to later steps (e.g. emit a ::warning::). See Interpreting the diff.

Related

Interpreting the diff Read the transition table and the action outputs.