Fork PRs and workflow triggers
Safe defaults for GitHub Actions when contributors open pull requests from forks—especially secrets, preview URLs, and pull_request vs pull_request_target.
This page complements your product security review and any PRD appendix on CI. It states defaults we expect for Restormel Testing in open or fork-friendly repos—not legal advice.
pull_request (recommended default)
Use a normal pull_request (or pull_request with path filters) workflow for suites that need secrets (Keys
tokens, preview URLs, private registry auth). GitHub does not expose your repo secrets to jobs triggered from forks on pull_request—so those jobs should skip or degrade gracefully when secrets are missing.
pull_request_target (high risk)
pull_request_target runs in the base repository context with access to secrets, while the checked-out
code can still be attacker-controlled from the fork. That combination is a common source of supply-chain issues. Do not adopt pull_request_target for Restormel Testing unless you have a separate security review and a
minimal, audited workflow (e.g. label-gated, no arbitrary code execution from PR head, no secret exfiltration).
Composite Action: fork policy
The MVP composite action defaults to fork_pr_policy: skip when is_fork_pr is true, so forked PRs do not fail
the job because secrets are unavailable. Only set fork_pr_policy: run when the suite is safe without secrets and targets a public URL you are willing to hit from GitHub’s network.
Implementation detail: packages/testing-github-action/README.md.