Closes the asymmetry between python-tests.yml (auto-fires on every PR
via pull_request) and unity-tests.yml (only fires on labeled
pull_request_target, or on push events). Same-repo PRs now get a
unity-tests status check immediately on open; fork PRs also get the
check but run in the fork's secret-less context, so the existing
detect step writes unity_ok=false and the job exits clean with a
"missing license secrets" notice. The status appears but signals the
fork-PR contributor that a maintainer needs to apply 'safe-to-test'
for a real run (existing gating pattern preserved).
Three changes:
1. Add 'pull_request: branches: [main, beta]' to the workflow triggers
with the same path filter as pull_request_target. The job-level if:
gates already pass through non-pull_request_target events, so no
gate edits are needed.
2. Extend the matrix selector to honor 'full-matrix' label on
pull_request events too, not just pull_request_target. Lets
in-repo PR contributors opt into the wide matrix at PR-open time
without waiting for the labeled-pull_request_target event.
3. Add a workflow-level concurrency group keyed on
`github.head_ref || github.ref`. Same-repo PRs would otherwise
fire both push (on the branch SHA) and pull_request (on the PR
SHA) and run the matrix twice; concurrency dedupes them.
Selector dry-run across the seven trigger cases confirms correct
behavior: default leg on unlabeled PR open / feature push; FULL on
labeled PR open + pr_target / push to beta / workflow_call /
workflow_dispatch.
Doc update in docs/development/README-DEV.md explains the new PR
status-check behavior and the fork-PR caveat.
Shutong Wu
a30e596d8a