ci: split PR workflow so build runs from PR head

[doodlum]

Problem

pr-checks.yaml used pull_request_target, which resolves workflow and action files from the base branch regardless of what the PR changes. This meant changes to .github/workflows/ or .github/actions/ could never be exercised by their own PR's CI — they silently passed all checks because nothing tested the new code.

Solution

Split into two workflows following the GitHub recommended pattern for separating untrusted builds from privileged operations.

pr-checks.yaml → pull_request trigger

• Resolves all files (workflow, actions, source) from the PR head
• Changes to .github/workflows/** and .github/actions/** are now actually exercised in PR CI
• Added those paths to the paths filter and the build_ci changed-files group so they trigger a full rebuild
• Removed prerelease and feature-audit-pr-comment jobs (moved below)
• Added save-pr-context job: uploads PR number, SHAs, version, and cpp-built flag as a short-lived artifact for the privileged workflow to consume

pr-privileged.yaml → workflow_run trigger

• Fires after PR: Checks completes, running from the base branch (trusted code)
• Downloads pr-context and dist-artifacts artifacts via cross-run artifact download
• Posts prerelease build and audit comment exactly as before
• Only fires for pull_request-triggered runs (github.event.workflow_run.event == 'pull_request')

Security model

Concern	Before	After
Who compiles fork code?	pull_request_target job (base branch workflow, fork code in WORKSPACE)	pull_request job (PR head workflow, fork code in WORKSPACE)
Token during compile	Read-only (no secrets: block)	Read-only (fork PRs always get read-only token under pull_request)
Who posts releases/comments?	Same pull_request_target workflow, elevated token	Separate workflow_run from base branch, elevated token
Fork code executes with write access?	No	No

The security properties are preserved. Fork PRs under pull_request receive a read-only GITHUB_TOKEN and zero repository secrets — GitHub enforces this unconditionally, regardless of what the fork's workflow file declares in permissions:.

Effect on existing PRs #2394 and #2395

Once this merges to dev, the pending optimization PRs can have their CI actually test the workflow/action changes they introduce, rather than silently passing against the base branch's versions.

Testing

This PR is self-referential: once it's non-draft, its own CI will run under the new pull_request trigger and exercise the changes it introduces. The pr-privileged.yaml won't exist on dev yet until merge, so the workflow_run portion will not fire — that's expected. The prerelease and audit comment behaviour can be verified on the first regular PR after merge.

---

Generated by Claude Code

[coderabbitai]

Important

Review skipped

Draft detected.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro Plus

Run ID: d38caa56-0298-4f02-b33c-4bf785f8521f

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch ci/split-pr-workflow

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}